Centos – Block RSA authentication when password is expired

centospassword-policyssh

I'm setting up a FreeIPA server on CentOS 7, and I want to block RSA authentication over SSH when the password is expired. By default, when I expire the user password and they login, they are forced to change their password. But, if that same user is also using RSA authentication, the server lets them in and does not force them to change their password. I've searched topics related to FreeIPA, PAM, and SSH, and can't seem to find the answer I am looking for.

Is there any way to block RSA key authentication over SSH when the user's password has expired?

Best Answer

If you have enrolled the client into FreeIPA, its PAM stack would be configured to use SSSD daemon. PAM module in question is pam_sss, which talks to SSSD daemon to perform the check. SSSD knows about IPA attributes and should properly deny session when user is locked out.

# ipa user-disable abbra
-----------------------------
Disabled user account "abbra"
-----------------------------
# grep UsePAM /etc/ssh/sshd_config
UsePAM yes
# journalctl -u sshd -f
 .....
Feb 29 17:21:23 a.example.com systemd[1]: Started OpenSSH server daemon.
Feb 29 17:21:33 a.example.com sshd[20209]: pam_sss(sshd:account): system info: [The user account is locked on the server]
Feb 29 17:21:33 a.example.com sshd[20209]: pam_sss(sshd:account): Access denied for user abbra: 6 (Permission denied)
Feb 29 17:21:33 a.example.com sshd[20209]: fatal: Access denied for user abbra by PAM account configuration [preauth]

For enabled user you would have something like:

# ipa user-enable abbra
----------------------------
Enabled user account "abbra"
----------------------------
# journalctl -u sshd -f
 ....
Feb 29 18:03:27 a.example.com sshd[22302]: Accepted publickey for abbra from X.Y.Z.W port 54540 ssh2: KEY...

When password is marked as expired (either by setting it by another user, i.e. admin, or by applying a certain password policy), SSSD ignores the fact that password needs a change because at this point it only runs an account phase where passwords aren't checked.

There used to be a number of requests to add such logic in past, with one of arguments against it was the fact that if you are using one type of authentication (public key) why should the account status be based on the state of another authentication type. There is a logic in it but perhaps it would be good to add a password policy that allows the logic to couple account state with password's state.

If you are interested in having such a password policy, I'd recommend to open a ticket to FreeIPA to request it, with an explanation of your use case.

Related Topic