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

[George Hansper]

Andy Armstrong wrote:
> George Hansper wrote:
> 

>> c) Once a user or host has been locked, there does not seem to be any
>>    way to unlock the account manually, before the 'purge' time has elapsed.
>>
>>    The locking appears to apply to a particular host, so I don't think this
>>    would arise except during testing. Once a host has exeeded it's failed-login
>>    limit, I would be reluctant to unlock it at a user's request.
> 
> 
> Yes, that's right. I will add it but normally it won't be necessary.
> 
>>    "user locking" appears to be "user-host locking", in that it is not the
>>    user's account which gets locked, but a particular user-host combination.
> 
> 
> No, it's actually user locking - it only considers the username. It's 
> less useful I think than host locking but it was trivial to add it so...
> 

I hate to contradict you, but this is what I get (Fedore Core 3 for this test):

>  ssh george at 127.0.0.1
george at 127.0.0.1's password:  (bad password)
Received disconnect from 127.0.0.1: 2: Too many authentication failures for george
>  ssh george at 127.0.0.1
george at 127.0.0.1's password:  (bad password)
Received disconnect from 127.0.0.1: 2: Too many authentication failures for george
>  ssh george at 127.0.0.1
george at 127.0.0.1's password:  (bad password)
Received disconnect from 127.0.0.1: 2: Too many authentication failures for george
>  ssh george at 127.0.0.1
george at 127.0.0.1's password:  (right password)
Received disconnect from 127.0.0.1: 2: Too many authentication failures for george
>  ssh george at 127.0.0.2
george at 127.0.0.2's password:  (right password)
Last login: Mon Jan 10 13:10:08 2005 from localhost


My /etc/security/pam_abl.conf is:

	host_db=/var/lib/abl/hosts.db
	host_purge=2d
	host_rule=*:5/1h,10/1d
	user_db=/var/lib/abl/users.db
	user_purge=2d
	user_rule=*:3/10m

If user-locking _really_ only considers the username, it is important to add an "unlocking"
command. Otherwise, a malicious user may take delight in locking out legitimate users.
I notice that the user-counter continues to increment, even after a host is locked out.

eg "hacker.com" tries 100 attempts on root, user1, user2, etc. Even though all
attempts are unsuccessful, the "Failed User" counter is still at 100 at the end of it,
and these users cannot access the system remotely until the timers in the DB have elapsed.

Personally, I think the user-host locking behaviour above is more useful that user-only locking.
It avoids the Denial-Of-Service vulnerabilty I mention above.

An unlocking command would still be useful, because a legitimate user may try many logins before
calling the relevant help-desk, and may have inadvertently locked their account or host.
(eg entering an old password, or a user-id for another system).

Regard,
	George Hansper