IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
"too many auth failures"?
I recently ran into some ssh behaviour that strikes me as broken and
thought I'd see what the list thought.
This is a semi-embedded commercial implementation; I'm not naming the
vendor here because this hasn't been reported to them yet, so it's
hardly fair to do anything even vaguely like name-&-shame now.
The symptom was that ssh to the device worked fine once, but when I
tried later, form a slightly different environment, I would
consistently get a "protocol error" failure. Upon turning on cleartext
packet tracing, it turned out that my client offered six public keys
(four in the agent and two from files), none of which were accepted.
When my client then tried to go keyboard-interactive in response to the
sixth key failure, the remote end sent an SSH_MSG_DISCONNECT with
reason code 2, SSH_DISCONNECT_PROTOCOL_ERROR, and a description string
saying there had been too many authentication failures for that user.
Disabling publickey auth in the client (which the client I was using
can do on the command line) got me a password prompt and I was able to
log in normally (thus indicating this did not mean "too many failures,
account locked"). The first attempts, the ones which worked without
any fuss, came from a different login, one which had only one key in
the agent and two in files.
This strikes me as wrong in two respects: (1) it's (apparently)
counting each failed public key as a separate "authentication" (okay,
three respects; that should be "authorization") failure, and (2) it's
claiming a protocol error for an error condition which is not in fact a
protocol error. It seems to me that it either should use a better
disconnet code (SERVICE_NOT_AVAILABLE, maybe?), or it should fail in a
userauth way - perhaps SSH_MSG_USERAUTH_FAILURE with an empty list of
authentication methods. (Hm, that's a botch in the RFCs I missed when
we were hammering them out; the "Authentication Protocol" is actually
more of an authorization protocol than an authentication protocol.)
So, thoughts? Am I missing something, or is this really as ill-behaved
as I think?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index