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._______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
