5

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?

3 Answers 3

2

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.

0

You could probably whip up a script using chage, or usermod, e.g.: usermod --expiredate ... If I had to I would use a shell script similar to the following pseudocode:

if `chage -l user_account_you_want_expired_etc | awk '/expires/{print "relevant fields}'` >= expiration
then
usermod -s /sbin/nologin USERNAME
fi

Something along those lines (mind you that is non-working but something to give you a framework. "If the expiry (grep'd from awk) is greater or equal to whatever I want/need it to be, then change the shell to nologin."

1
  • I was thinking the same thing, but I was worried that the user would not be able to log in to reset their password once it expired. If I do set the expiredate as you mention, is that the same as the pwdExpire in ldap?
    – sKr0d
    Feb 29, 2016 at 15:21
0

If you are using PAM to create session for your users (usePAM yes), it will not allow user to log in with expired passwords.

It is nicely described on Unix (ok, it is the reversed problem, but might be helpful to you).

1
  • CentOS 7 is configured for "usePAM yes." The issue may be the fact that FreeIPA uses "krpPassExpiration" in ldap instead of pwdExpire or whatever Pam looks at to determine if the account should force a password change. Maybe there is a way to have PAM look at that field as well?
    – sKr0d
    Feb 29, 2016 at 15:19

You must log in to answer this question.

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