pam_tally with sshd: ssh password-based failures not tally'd

[George Hansper]

Hi Tomas,

Thanks for working on this module. I haven't looked at the code,
but it seems that the 'auth' part of module is not rejecting the
login, but rather just incrementing the counter.

I tried adding 'deny=3' to the line:
	auth       required     pam_tally.so no_magic_root deny=3
but it had no effect.

I'm not sure how the pam_tally module interacts with the faillog(8)
program. They share the /var/log/faillog file, but the command:

	faillog -m 7

would be at odds with the 'deny=3' parameter in the /etc/pam.d/sshd file

Regards,
	George Hansper


Tomas Mraz wrote:
> On Thu, 2005-01-06 at 16:25 +1100, George Hansper wrote:
> 
>>Hi,
>>
>>I've been looking at pam_tally as a means of discouraging "brute force"
>>ssh attacks. I have noticed, like Adam Monsen in a previous e-mail:
>>
>>    http://www.redhat.com/archives/pam-list/2004-October/msg00047.html
>>
>>that once the maximum password failures has been exceeded,
>>SSH/PAM still give a clear indication of when you've cracked the right password.
>>
>>If you give a bad password, you get a 2-second delay and a new prompt:
>>
>>    dummy at localhost's password:
>>    Permission denied, please try again.
>>    dummy at localhost's password:
>>
>>If you get it right, you get the message:
>>
>>    dummy at localhost's password:
>>    Read from remote host localhost: Connection reset by peer
>>    Connection to localhost closed.
> 
> ...
> 
>>Is there some configuration change I can make to pam/ssh which will
>>fail a "locked" account in a consistant manner, regardless of whether
>>or not the password is right?
>>
>>Or is this already the subject of a bug-report/enhancement-request?
> 
> 
> Yes, this is a long known bug. I'm just working on improving the module
> so it will not have this problem.
>