How to use PAM to manage lockout policy for ssh public key authentication methods

Question

I have followed instructions on redhat on how to harden authentication on a linux server, but we only use SSH with public key auth. According to these instructions: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-hardening_your_system_with_tools_and_services

Here is my /etc/pam.d/system-auth and /etc/pam.d/password-auth files, they are both the same actually:

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60 auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_faillock.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 

With this config, I was hoping to achieve some kind of lockout message if user tries to authenticate with the wrong key after 3 tries for example. But no message about lockout pops up, and I have no way to tell if lockout policy is working or not. There is also the pam_tally2 module, but I don't see what difference it would make vs the pam_faillock module.

The logs show nothing except that root permission denied:

[some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/some_user [some_user@ip-10-10-2-53 ~]$ cat /var/run/faillock/root cat: /var/run/faillock/root: Permission denied 

And I have tried to use the wrong key to ssh for some_user, and it does not seem to lock me out because I don't see anything in the faillock logs or any ssh message from where I try to ssh.

Answer 1

The problem is that you're trying to enforce these policies inside of the auth stack.

auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=60 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=60 auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_faillock.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 

Public key authentication implemented within the SSH daemon itself bypasses the auth stack. (there's no PAM auth module being called to validate the submitted key, so it has to work that way) The sole exception is when you're running a customized configuration that requires success inside of keyboard-interactive as well. Since this is not the default, your auth stack is almost certainly being ignored during these authentications.

While the account stack is usually where you place restrictions on publickey-only logins, I don't believe that will work here as you would first have to succeed at authenticating in order for the PAM module to be called. If your PAM module isn't being called, it isn't able to increment a count with each failed login.

The only way I can see this working is if you adjust your sshd configuration to require keyboard-interactive authentication in addition to public key authentication. (you can use this Q&A as a starting point) That said, as JohnA points out it is debatable whether this would truly provide any value.

Answer 2

I'm pretty sure that you won't be able to use PAM in this capacity. If the user does not have the ssh private key that corresponds to the ssh public key on the server, then they will not be able to authenticate.

The purpose of password failure lockout is to prevent brute forcing of the password on a user account. If ssh key authentication is enforced, there is no user account password to take into account.

In the case of the password that is requested for ssh key auth, this is the password for the private key. Failure to authenticate against the private key does not result in any authentication failure to the server.