1

There is a similar behavior here but I believe this is a different underlying cause, or at least requires a different solution since this failure isn't due to SSH keys.

Our company is undergoing a Linux audit and I need enable PAM account locking for 3 bad password attempts. I have no previous PAM experience.

If I run pam_tally2 -u testuser immediately after running su testuser but before entering the password, the pam_tally for failures is already 1, even though I have not yet entered a password.

I understand that in the case I linked to above that the pre-password-increment is caused by a failed SSH key exchange, but after reading man su it doesn't seem like a key exchange is involved. So my question is "why does su cause pam_tally to increment before entering a password?"

I'm doing my best to make sure the login attempts/blocks all match between sshd_config, PAM, fail2ban, and /etc/login.def, but it's tricky when pam_tally counts events I'm not expecting!

OS is Ubuntu server 14.04

Only PAM config changes made to server are in /etc/pam.d/common-auth adding this line at the top: 

auth    required pam_tally2.so deny=3 unlock_time=900

Thanks!

devLP
  • 11
  • 3
  • Just to be clear, what does `pam_tally2 -u testuser` report after the correct password is entered? And what is the behaviour when 2 unsuccessful attempts have been made and you attempt a third time? – Johnny Nov 07 '18 at 19:33
  • After the correct password is entered the failed count goes to 0. After 2 unsuccessful attempts and then a successful attempt it resets to 0 (and logs in) correctly as well. So I will say it behaves as it should security-wise, but the feedback is odd. I wouldn't expect -u to report a failed attempt before password entry. Also, if I fail 3 attempts, get locked out, and attempt a 4th, it says "4 failed logins" before password entry, when again, I've only had 3 failures. It seems to tally before password entry and uses that number for all prompts, which is very misleading to the user IMO. – devLP Nov 07 '18 at 20:07

1 Answers1

2

A careful reading of what pam_tally2 does will fully explain the behaviour you're seeing. You're expecting to see how many failed attempts at login have occurred; however, the man page explains (emphasis mine):

This module maintains a count of attempted accesses

So it's behaving exactly as intended. When you su user, regardless of whether you have yet typed a password (correct or incorrect), you have immediately attempted access. When you subsequently enter a correct password, the tally resets to 0. You have set the maximum attempts to 3, so you get an error as soon as you have exceeded that — it is the 4th attempt that generates the error.

The behaviour is correct, and now that we understand what pam_tally2 actually does, it's reasonable.

Johnny
  • 170
  • 7
  • Thank you. That explains the behavior. However, I'd like to point out for anyone else confused by the error messages that the first pre-password-entry attempt *after* a lockout states "Account locked due to {X+1} failed logins" even though I've only submitted X passwords, where deny=X. Only the most ruthless of teachers would tell you that you failed a test before you've taken it! – devLP Nov 07 '18 at 21:29