The pam_radius module's man page purports to be able to support a "template user", i.e. when a user not listed in the local system attempts to authenticate when pam_radius is in effect, instead, the login credentials for "template_user" will be presented. FreeBSD seems to authorize against radius correctly when a local user exists, but when a non-local user tries to authenticate, the request is NOT EVEN FORWARDED to the radius server. Auth simply fails. Fix: None known. How-To-Repeat: /etc/radius.conf: auth 65.125.237.37 testing123 acct 65.125.237.37 testing123 /etc/pam.conf: sshd auth sufficient pam_skey.so sshd auth sufficient pam_opie.so no_fake_prompts #sshd auth requisite pam_opieaccess.so #sshd auth sufficient pam_kerberosIV.so try_first_pass #sshd auth sufficient pam_krb5.so try_first_pass sshd auth sufficient pam_radius.so try_first_pass template_user=danm sshd auth required pam_unix.so try_first_pass sshd account sufficient pam_radius.so try_first_pass template_user=danm sshd account required pam_unix.so sshd password required pam_permit.so sshd session required pam_permit.so try to log in as a user who is present on the radius server but not present on the local system.
Any hope for a patch re: template_user and pam_radius? Running 6.0-RC1 and template_user doesn't seem to work. Any workaround? Thanks, Tate
Tue, 1 Nov 2005 16:43:20 -0500 (EST)n Tue, 1 Nov 2005, C. Tate Baumrucker wrote: I wouldn't hold your breath. Personally, this little bug shot to hell any hope of using radius for central auth on all our systems (because radius is a great common denominator, even windows can speak it!) At the very least, the notation about the function should be removed. I'd fix it, but I do not speak C and have no IDEA where to even go about trying to run a truss on something as crucial as PAM. -Dan -- "Happy, Sad, Happy, Sad, Happy, Sad, Happy, Intruiged! I've never been so in touch with my emotions!" -AndrAIa as Hexadecimal, Reboot Episode 3.2.3 --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------
State Changed From-To: open->closed This is actually a configuration error. At the point where pam_radius submits an authentication request to the server, it doesn't know (or care) whether the user exists in the local user database. It doesn't make that check until after the user has been authenticated by the radius server. The only explanation for this is that the originator had something in their PAM configuratin that rejected the authentication attempt before it ever reached pam_radius. This could easily have been verified by enabling debugging with the "debug" keyword in the appropriate PAM stack.
The problem I have with this explanation is that when pam_radius is configured with the template_user pam sends an invalid password hash to my radius server, causing my radius server to reject the auth. When I create a local user account and remove template_user, it works as expected.
Further to this, I have inserted some debug output into pam_radius.so.5 to output the password to syslog from the build_access_request. When I have a local user account matching the login I am using it works correctly and logs me in and syslog shows my password as expected: Aug 11 17:09:22 ssi-knta-pd1 sshd[5464]: rad_mb_debug: MySecret When I remove the local user account pam_radius uses the incorrect password when generating the password hash for the radius packet. Aug 11 17:09:48 ssi-knta-pd1 sshd[5473]: rad_mb_debug: ^H ^M^?INCORRECT
The problem is that OpenSSH checks whether the user exists before attempting authentication. Moreover, the OpenSSH developers consider this functionality a security liability and have intentionally removed it from their code (see https://blog.des.no/2015/08/openssh-pam-and-user-names/). Therefore, we will not fix this.
*** Bug 169670 has been marked as a duplicate of this bug. ***
*** Bug 124320 has been marked as a duplicate of this bug. ***