2

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.

alexfvolk
  • 164
  • 1
  • 9

2 Answers2

4

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.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
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.

JohnA
  • 556
  • 3
  • 12