pam_abl and sshd MaxAuthTries strangeness (was Re: pam_tally with sshd: ssh password-based failures not tally'd)

[Darren Tucker]

George Hansper wrote:
[...]
> In general, it seems for 'MaxAuthTries N', I get N+1 tries at the password,

This appears to be a case of C-programmer disease (ie counting from zero 
not one) in sshd.

> and pam_abl increments by ONE failed login.
[...]
> If no password was entered this did NOT register as a failed password 
> for pam_abl.

Short answer: this is probably because you have "PermitEmptyPasswords 
no" in sshd_config.

Long Answer: there are places that the PAM API and SSH2 protocol don't 
quite see eye to eye, and this is one of them.

One part of the protocol is the "none" authentication type, which the 
spec defines as (paraphrasing) "if no further authentication is 
required, allow the login, else return a list of authentications that 
can continue".  OpenSSH implements the "none" authentication as a 
password authentication attempt with no password, which is what's needed 
on most platforms.

There is, however, a fly in the ointment with PAM.  How do you ask PAM 
"does this user require a password to log in"?  Well, you can't, really. 
  The best you can do is just have your conversation function return an 
empty password or just PAM_CONV_ERR, then call pam_authenticate().

With a bit of luck, if your user has an empty password then 
pam_authenticate() will succeed immediately, the conversation function 
will not be called and sshd will let the user log in.  Otherwise, sshd 
sends the list of allowed authentications and the client tries again.

This works but has a couple of downsides:
1) A failed auth attempt is logged by PAM for the "none" auths, ie for 
*every* login.
2) If you have PAM insert a delay on fail then *all* logins will be 
needlessly delayed, regardless of whether or not they ulimately succeed.

So, as a compromise, sshd won't try PAM at all for empty passwords and 
the "none" auths if PermitEmptyPasswords=no.

> This gives rises to the possibilty of a publickey ssh attack, which is 
> not picked up by pam_abl.
> Is there some way to make failed publickey logins register with pam_abl?

The only way I can see if the module could hook into pam_start() 
somehow, but AFAICT there's no hook in the module interface for that.

> Although I understand what was happening now, I did find it confusing at 
> the time.
> 
> Firstly, that 'MaxAuthTries N' allows up to N+1 authentication attempts 
> (across all methods),
> and secondly, that try-once-and-give-up methods like 'publickey' are 
> included in this count.

Public-key isn't "try-once-and-give-up".  You can have an arbitrary 
number of attempts (eg if you have an agent full of keys).

> It might be more useful to end-users to have separate controls in 
> /etc/ssh/sshd_config
> for the different methods - eg MaxAuthTriesPassword, 
> MaxAuthTriesPublickey etc.

I don't see much value in that.  MaxAuthTries is just a safety valve to 
prevent too many attempts in a single connection.  The attacker can 
always reconnect (at a cost of some CPU for key exchange).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.