pam_tally2 reset problems with many simultaneous connections

Daniel Neuberger daniel.neuberger at
Fri Jun 7 23:25:51 EST 2013


(Sorry if this is a repost, I tried without being a subscriber and saw 
nothing after a day, so I'm trying again after subscribing).

I think this is a problem with how sshd uses PAM.  Basic scenario:

- sshd is configured to use PAM with pam_tally2
- Multiple clients try connecting within a small time frame
- Some of the clients fail to authenticate

The problem is that the tally is incremented for every authentication, 
but isn't necessarily reset for successful authentications before 
another client tries to authenticate.  So it goes something like this:

- Client A authenticates successfully, but doesn't yet reset the tally
- Client B tries to authenticate, but gets locked out for 10 seconds
- Client C tries to authenticate, but gets locked out for 10 seconds
- Client D tries to authenticate, but then the account is locked entirely
- Client A finally resets the tally in the account phase
- Client B tries again and authenticates successfully

So, if a server is under load with many sftp connections, you'll see 
lots of logs even though everything eventually succeeds.

I'm on RHEL 5.5 with openssh-server-4.3p2-41.el5 and pam-

I'm using pam_tally2 in the auth and account phases:

auth       requisite deny=3 lock_time=10 unlock_time=900
account    required

I'm guessing the problem is that sshd doesn't call pam_setcred correctly 
as stated in the pam_tally2 man page:

"Account phase resets attempts counter if the user is not magic root. 
This phase can be used optionally for services which don't call 
pam_setcred(3) correctly or if the reset should be done regardless of 
the failure of the account phase of other modules."

We had a similar problem with vsftpd once and solved it by not using 
pam_tally2, but I don't really want to do that for sshd.

Has anyone else run into this problem before or have any suggestions for 
solving it?

I searched google, the mailing list, and the bug list and couldn't find 


- Daniel

More information about the openssh-unix-dev mailing list