I'm trying configure my SSHD's to authenticate users using FreeRadius. The FreeRadius server needs to first require a valid OTP using Google Authenticator, and then verify the system account password.

I can get things working if I set the Radius server to only use Google Authenticator, but when I add the additional step of asking for the system account password, the Google Authenticator token fails every time. I think my problem is my PAM configuration, but I don't see what I'm doing wrong with it.

I'll call the server running SSHD the "client" server and the FreeRadius server the "radius" server.

Here is my client:/etc/pam.d/sshd

auth       required     pam_sepermit.so
auth       required     pam_radius_auth.so debug prompt=token
#auth       include      password-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      password-auth
account    sufficient   pam_radius_auth.so
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin

I have also enabled challenge/response authentication in the client:/etc/ssh/sshd_config with the line:

ChallengeResponseAuthentication yes

Here is my /etc/pam.d/radiusd config on the radius server:

auth       requisite    pam_google_authenticator.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
session    include      password-auth
#@include common-auth
#@include common-account
#@include common-password
#@include common-session

And just so you can follow the chain, here is the /etc/pam.d/password-auth file on the radius server:

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The way this is supposed to work, is the client server only needs the radius server to accept in order to accept the login, but the radius server needs both OTP with GoogleAuthenticator and the local pam_unix password in order to accept. This is what I want.

Curiously, when I comment out on the radius server /etc/pam.d/radiusd file the line:

auth       include      password-auth

I can then log into the client server and it will prompt me for my GoogleAuthenticator token. Everything works when I do this. The OTP I get from my phone is accepted, the request is sent to radius, it comes back to the client server, and lets me in.

But if un-comment the above line, I'm asked for my GoogleAuthenticator token, and every time I type it in, it fails. Weirdly, it asks me for the OTP token 4 times, and then asks me for the system account password, and then says it failed. Can anyone help me to get this working?

Here is my debug output from "radiusd -X" when I try to use both the GoogleAuthenticator token and the unix password:

Received Access-Request Id 112 from client:48253 to radius:1812 length 94
        User-Name = ‘bob’
        User-Password = '146963'
        NAS-IP-Address = client
        NAS-Identifier = 'sshd'
        NAS-Port = 9148
        NAS-Port-Type = Virtual
        Service-Type = Authenticate-Only
        Calling-Station-Id = ‘xxx.xxx.xxx.xxx’
(0) Received Access-Request packet from host port 48253, id=112, length=94
(0)     User-Name = ‘bob’
(0)     User-Password = '146963'
(0)     NAS-IP-Address = xxx.xxx.xxx.xxx
(0)     NAS-Identifier = 'sshd'
(0)     NAS-Port = 9148
(0)     NAS-Port-Type = Virtual
(0)     Service-Type = Authenticate-Only
(0)     Calling-Station-Id = ‘xxx.xxx.xxx.xxx’
(0) # Executing section authorize from file /etc/raddb/sites-enabled/default
(0)   authorize {
(0)   filter_username filter_username {
(0)     if (!&User-Name) 
(0)     if (!&User-Name)  -> FALSE
(0)     if (&User-Name =~ / /) 
(0)     if (&User-Name =~ / /)  -> FALSE
(0)     if (&User-Name =~ /@.*@/ ) 
(0)     if (&User-Name =~ /@.*@/ )  -> FALSE
(0)     if (&User-Name =~ /\\.\\./ ) 
(0)     if (&User-Name =~ /\\.\\./ )  -> FALSE
(0)     if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/))  
(0)     if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/))   -> FALSE
(0)     if (&User-Name =~ /\\.$/)  
(0)     if (&User-Name =~ /\\.$/)   -> FALSE
(0)     if (&User-Name =~ /@\\./)  
(0)     if (&User-Name =~ /@\\./)   -> FALSE
(0)   } # filter_username filter_username = notfound
(0)   [preprocess] = ok
(0)   [chap] = noop
(0)   [mschap] = noop
(0)   [digest] = noop
(0)  suffix : Checking for suffix after "@"
(0)  suffix : No '@' in User-Name = “bob”, looking up realm NULL
(0)  suffix : No such realm "NULL"
(0)   [suffix] = noop
(0)  eap : No EAP-Message, not doing EAP
(0)   [eap] = noop
(0)  files : users: Matched entry DEFAULT at line 198
(0)   [files] = ok
(0)   [expiration] = noop
(0)   [logintime] = noop
(0)  WARNING: pap : No "known good" password found for the user.  Not setting Auth-Type
(0)  WARNING: pap : Authentication will fail unless a "known good" password is available
(0)   [pap] = noop
(0)  } #  authorize = ok
(0) Found Auth-Type = PAM
(0) # Executing group from file /etc/raddb/sites-enabled/default
(0)   authenticate {
pam_pass: using pamauth string <radiusd> for pam.conf lookup
pam_pass: function pam_authenticate FAILED for <bob>. Reason: Authentication failure
(0)   [pam] = reject
(0)  } #  authenticate = reject
(0) Failed to authenticate the user
(0) Using Post-Auth-Type Reject
(0) # Executing group from file /etc/raddb/sites-enabled/default
(0)  Post-Auth-Type REJECT {
(0)  attr_filter.access_reject : EXPAND %{User-Name}
(0)  attr_filter.access_reject :    --> bob
(0)  attr_filter.access_reject : Matched entry DEFAULT at line 11
(0)   [attr_filter.access_reject] = updated
(0)  eap : Request didn't contain an EAP-Message, not inserting EAP-Failure
(0)   [eap] = noop
(0)   remove_reply_message_if_eap remove_reply_message_if_eap {
(0)     if (&reply:EAP-Message && &reply:Reply-Message) 
(0)     if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
(0)    else else {
(0)     [noop] = noop
(0)    } # else else = noop
(0)   } # remove_reply_message_if_eap remove_reply_message_if_eap = noop
(0)  } # Post-Auth-Type REJECT = updated
(0) Delaying response for 1 seconds
Waking up in 0.9 seconds.
(0) Sending delayed response
(0) Sending Access-Reject packet to host xxx.xxx.xxx.xxx port 48253, id=112, length=0
Sending Access-Reject Id 112 from xxx.xxx.xxx.xxx:1812 to xxx.xxx.xxx.xxx:48253
Waking up in 3.9 seconds.
(0) Cleaning up request packet ID 112 with timestamp +20
Ready to process requests
Received Access-Request Id 81 from xxx.xxx.xxx.xxx:45486 to xxx.xxx.xxx.xxx:1812 length 94
        User-Name = ’bob’
        User-Password = '146963'
        NAS-IP-Address = xxx.xxx.xxx.xxx
        NAS-Identifier = 'sshd'
        NAS-Port = 9149
        NAS-Port-Type = Virtual
        Service-Type = Authenticate-Only
        Calling-Station-Id = ‘xxx.xxx.xxx.xxx’
  • I think this definitely has to do with radius being in the mix. Taking radius out of the equation and just using pam_google_authenticator.so on a local box along with the standard pam_unix.so works just fine. The local SSH server asks for the token, then the account password, and lets me in.
    – noderunner
    Oct 7, 2015 at 19:49

1 Answer 1


I figured it out. The problem was in the PAM stack for the /etc/pam.d/password-auth file. Specifically this line:

auth        sufficient    pam_unix.so nullok try_first_pass

What was happening is that the token for google-authenticator was being accepted, but then pam_unix.so was trying to use that code as the system password because of the "try_first_pass" option. I'm not sure why, but this was causing the entire authentication chain to start all over again, asking for the google-auth password.

Getting rid of the "try_first_pass" option fixes the issue and gives me the desired behavior.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .