2

I'm running RHEL 6.2. Most users will be using SSH to login using passwords. Some might have keys. All accounts are local.

I need to lock users out after N failed password logins.

The examples in man pam_tally2 and pam_faillock do not lock a user using ssh out. The pam_tally2 example can lock a telnet (I enabled to test) login & subsequently will lock an ssh user out. ssh cannot trigger it.

/etc/ssh/sshd_config has:

PasswordAuthentication yes # setting to no doesn't allow login with a password!
UsePAM yes
UseLogin no # setting to yes doesn't allow putty logins

Man page examples should work on an unaltered system.

  • This doesn't answer your question directly, but, try fail2ban. (It's in EPEL.) – mattdm Feb 12 '13 at 1:19
2

If you enable PasswordAuthentication then the SSH daemon handles passwords itself and not using PAM. You actually want to disable this in order to force it to use PAM:

PasswordAuthentication no
UsePAM yes
ChallengeResponseAuthentication yes

That won't catch users using keys however (although personally I think that's fine). If you do you'll probably have to use something like fail2ban which looks for authentication failures in the logs and adds iptables rules to block future attempts.

1

You'll need to add the following lines to /etc/pam.d/sshd:

auth       required     pam_tally2.so deny=6 onerr=fail unlock_time=1800
account    required     pam_tally2.so

Add them on lines 3 and 6 as indicated below:

#%PAM-1.0
auth       required     pam_sepermit.so
auth       required     pam_tally2.so deny=6 onerr=fail unlock_time=1800
auth       include      password-auth
account    required     pam_nologin.so
account    required     pam_tally2.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      password-auth

Also make sure UsePAM yes is set in /etc/ssh/sshd_config

This will lock an ssh user out for 30 minutes after six failed authentication attempts.


If we follow the official RHEL 6 Security Guide, we can accomplish this without changing /etc/pam.d/sshd.

We edit both /etc/pam.d/system-auth and /etc/pam.d/password-auth, replacing

auth        sufficient     pam_unix.so nullok try_first_pass

with

auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        sufficient     pam_unix.so nullok try_first_pass
auth        [default=die]  pam_faillock.so authfail audit deny=3 unlock_time=600

And, in both files, we add this line to the top of the "account" section:

account     required      pam_faillock.so

This will provide account lockout functionality to console users, screensaver users, and so on.

If you examine /etc/pam.d/sshd you can see it uses password-auth and therefore ssh users will experience the same lockout functionality.

  • I follow the RHEL one, and do get locked out when using SSH, but message does not display that I am locked out, but when I locally try to lock myself out I see the message.. I don't understand why. – alexfvolk Mar 26 '18 at 18:14
0

I had to edit '/etc/pam.d/sshd '

with

Auth required pam_tally2.so Deny=5 Unlock_time=1200 Even_deny_root Root_unlock_time=10

and it works now.

0

Discrepancy in the behavior of unlock_time in pam_faillock when compared with pam_tally. (unlock_time is not drifted according to the last failed attempt) Configure pam_faillock in system-auth and password-auth with deny=3 and unlock_time=300, Now try to login with any non-root user and enter invalid password 3 times after which the account gets locked as expected, say the current time is 1300 hrs. The account locks out and you will not be allow to login with correct password until 13:05 hrs, If the user again tries to login again at 13:02, system denies as account is locked-out. For the same scenario, In case of pam_tally, as user attempts to login at 13:02, the user will be unlocked only after 13:07 instead of 13:05. unlock_time is drifted after failed attempt and adjusted here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.