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

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
  • 180