Linux password aging and ssh keys

Recently I have been playing with password ageing and the usage of ssh keys. I have found that if usePAM yes (default) is set in the /etc/ssh/sshd_config file then any password ageing and inactiivity can adversely affect a client with ssh keys.

For example:
Set PASS_MAX_DAYS to 60 in /etc/login.defs (for new user accounts)
set INACTIITY=30 in /etc/default/useradd (for new user creations)

Here is an example of one done already:

# chage -l test01
Last password change				: Mar 27, 2015
Password expires					: May 26, 2015
Password inactive					: Jun 25, 2015
Account expires						: never
Minimum number of days between password change		: 0
Maximum number of days between password change		: 60
Number of days of warning before password expires	: 7

• Login with test01 today's date no problem.
• Set date to May 27, 2015... Upon login, you are told the password has aged and you are FORCED to change your password.
• Set date to June 26, 2015 ... After login, you are informed your password has expired and to contact your system administrator and the connection is dropped.

Same scenario.. except this time you will be logging on with your ssh key (instead of password):

• Today's date ... login normally
• Set date to May 27, 2015 ... Login with key, but told your password aged and it forces you to change your password
• Set date to June 26, 2015.... Login with key, told your account is expired and dumps the connection.

If you change "usePAM no" in the /etc/ssh/sshd.config file and restart the ssh daemon and retry the following happens: (using ssh key)

• Today's date.. login normally
• Set date to May 27, 2015 ... log on no warnings.
• Set date to June 26, 2015 ... log on no warnings.

Do again, using password instead of ssh key:

• Today's date ... logon normally
• Set date to May 27, 2015 ... log on, password change forced
• Set date to June 26, 2015 ... log on, password change forced (the inactivity is NOT being honored).

So in summary:
If you use password ageing and "usePAM yes" you are prompted to change password, even if using ssh keys.
If you use password ageing and "usePAM no" your password never goes INACTIVE and ssh keys work without password expiration warnings.

Trying to get best of both worlds:
Use password ageing + inactivity ... but not affect anyone using ssh keypairs.

For reference, here is the relevant changes to the pam files. (note I have done this for RHEL4,5 and 6. As well as Debian 7. So of course, config files same (except RHEL4) and PAM configuration files slightly different due to different distros.

RHEL5/6: (note: rhel6 also has the settings in /etc/pam.d/password-auth-ac)
/etc/pam.d/system-auth-ac

auth        required      pam_tally2.so onerr=fail deny=3
account     required      pam_tally.so
password    requisite     pam_cracklib.so try_first_pass retry=3 lcredit=0 ucredit=0 ocredit=0 dcredit=0 minlen=8
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok remember=5

Suggestions ?

I missed the point. What you describe is correct. It works so. What sort of suggestions do you want to receive? You don't want to use PAM and implement password aging in SSH? Or you want to use PAM and implement something (what?) using PAM?

I guess it's a two-edge sword. 1) I am wondering why password aging is affecting ssh-keys. I would think they should be different. 2) Trying to have user accounts using passwords to fall under the password restrictions. At the same time, having ssh keys unaffected by the password restrictions.

what I personally don't like on ssh is that it has its own authentication system. Setting UsePAM Yes you effectively say to bypass ssh's own authentication and use system authentication, but system authentication doesn't know anything about ssh-keys. It usually uses passwords and you instruct it to check, whether the passwords are expired or not. For PAM it doesn't matter anymore from this point if the user was authenticated using a password or an ssh-key. The user is authentication and PAM must check its password expiration, what it does.

If you want to switch off password aging rules, you can do it on system-wide basis ( UsePAM No ) or on per-user basis( chage ), but not on basis of authentication method the user used.

On the other way you can supply for ssh its own ssh PAM configuration, but I really don't know how to check, if a user was authenticated using pubkey or password.

This problem, among other things, is why folks use centralized login system like LDAP and/or Kerberos.

Personaly, in my environment i had such issues,with users using keys, other using passwords. It was a nightmare when a count of those users increased and environment got more heterogeneous (various operating system).

'Solution' came to me in LDAP/Kerberos included in AD with tickets. 99% of the clients connected with putty/winscp or similar software which all support kerberos auth with SSO.

Works for most web servers (mod_krb), to implement SSO on every possible service transparently, even web services talking to each other etc.

Point is...

Users loved it - they only need to know their domain password and log onto the domain PC, everything else is a click away with SSO.
Auditors loved it - they get information from a central place (the domain controller in this case), it is secure (kerberos seems bulletproof for now).
Administrators praised it - no more administrative overhead with users on any application.

Hope that helps
Regards
Peasant.

Thanks for the suggestions on other scenarios. However, I am not able to bring the vendors around and what-not to do the domain. They might of initially, but since the systems are already setup / configured that isn't an option. Thus I'm stuck between a rock and a hard place. Disabling usePAM I have already looked into, and it breaks the "password inactivity", so that doesn't help any. Not sure if there is another PAM module that can be used, or to use say use the "password" field instead of the "auth" field to work around the problem. I also have an open incident with Redhat, so hopefully that will shed some light on the matter as well. cheers.