Bug 124320 - pam_radius(8): Login with ssh using pam_radius and a template_user
Summary: pam_radius(8): Login with ssh using pam_radius and a template_user
Status: Closed DUPLICATE of bug 66095
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Dag-Erling Smørgrav
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-05 21:00 UTC by Jacco van Buuren
Modified: 2015-12-17 20:24 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacco van Buuren 2008-06-05 21:00:12 UTC
PAM_RADIUS doesn't work with a TEMPLATE_USER for remote logins with SSHD.

The situation is as follows:

A radius authorization backend system, server A, has user ALICE, with a password, and user BOB, with a password.
Another server, server B, is using PAM_RADIUS for radius authentication on SSHD for remote logins. While attempting to figure out how pam_radius works on server B, pam (/etc/pam.d/sshd) is configured like this:

auth            sufficient      pam_radius.so           try_first_pass template_user=bob debug
account         sufficient      pam_radius.so           template_user=bob debug
password        sufficient      pam_radius.so           try_first_pass template_user=bob debug

On server B, Bob has a plain vanilla Unix account in /etc/passwd, with an existing shell and homedirectory. When using the pam config shown above, Bob is asked for his radius password from server A (as expected) when he tries to login
with ssh. This works perfectly Ok for Bob: Radius authentication is working on server B when using ssh to login - in this case regardless of his password. So far so good.

Since Bob has special privileges on server B, his account will be the template for a small group of other users, effectively sharing the bob-account - not Bobs' password - with others.
Template_user should provide for this, from the pam_radius man-page:

[..]"template_user=username
specifies a user whose passwd(5) entry will be used as a tem- plate
to create the session environment if the supplied user- name does not exist in local password database.  The user will be authenticated with the supplied username and pass- word, but his credentials to the system will be presented as the ones for username, i.e., his login class, home directory, resource limits, etc. will be set to ones defined for username.

If this option is omitted, and there is no username in the system databases equal to the supplied one (as determined by call to getpwnam(3)), the authentication will fail."[..]

As pam is configured with 'template_user=bob', it would be expected that user 'alice' - an account that doesn't exist on server B in /etc/passwd - should be able to login with ssh since Bob can login... Oddly enough, logging in ONLY
works for user 'alice' when the account exists in /etc/passwd on server B. Which
would still require all the accounts being present on server B, and thus defeating the purpose of a template_user. It seems that template_user has no
effect, no matter which password (alice/bob) is used. Sshd is actually complaining about pam: "fatal: Internal error: PAM auth succeeded when it should have failed".

From what I've googled it seems that this topic is returning every now and then,
without any clear solution. Some do indeed point to OpenSSH
(http://www.usenet-forums.com/openssh-development/336942-sshd-pam_radius-under-freebsd.html#post706102).
I haven't tested this with telnetd or others. To put it another way: I've found no document that explains why a pam_radius template_user shouldn't work with sshd.

Fix: 

-
How-To-Repeat: Configure a radius server (Freeradius or so) and very it's working properly. Configure a radius cleint on another system (radius.conf). Then configure /etc/pam.d/sshd to make use of the template_user feature.
Comment 1 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2015-12-17 20:24:05 UTC

*** This bug has been marked as a duplicate of bug 66095 ***