Re: "too many auth failures"?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> Shouldn't the client know which key it's supposed to use?
>> How should it know that?
> By keeping track of which key belongs to which server.  When I sign
> in to gmail I (meaning Firefox acting on my behalf) don't try forty
> different passwords in the hope that one fits, I send the exact
> password that's used for gmail.  Why is the SSH client unable to do
> the same thing for a public key?

Well, in the most naïve form, the answer is "because I never
implemented it" (mutatis mutandis for those using other
implementations).

But it's worth thinking about why the difference arises.  The biggest
difference, I think, is simple: the damage potentially done by trying
inappropriate keys is substantially less than that done by trying
inappropriate passwords.  If you reveal to me the public key for the
key pair you to ssh-authenticate yourself to (say) your employer, I
don't learn enough to do anything significant.  But if you send me your
gmail password then I can trivially impersonate you to gmail.  This
makes it far more reasonable for your ssh client to not bother keeping
track of which keys work for which servers - and, at the same time, far
more reasonable for you to use the same key for disparate servers.

Also relevant: there reasonably can be (and often are) many keys which
work for a single login.  There rarely are multiple passwords which
work for a single login.

That said, the ability to for the client to be told, or perhaps even
autolearn, what keys work for what servers is probably a desirable
thing, even if not particularly valuable in many cases.  It does,
however, appear to be comon for clients to not do it.

>> [...client just tries keys it has available...]
> That sounds like really, really broken behaviour.  You're saying the
> client is totally unable to keep track of which key is used to
> authenticate to which server, and just tries them at random in the
> hope that one fits?

Generally, yes.  (Well, for weak values of "random".)

> That would be like Firefox (see above) trying every stored password
> it knows for every site in the hope that one works.

Except significantly less bad; see above.

> There are an awful lot of password managers around for browsers with
> a huge number of users (the Roboforms one, the last time I checked,
> claimed 28 million downloads), and none of them resort to this kind
> of brokenness.

Because with passwords, you can't really do that; the exposure is too
high.  One of the nice things about public-key auth is that you _can_
do that without significant ill effects.

> This could even be a security problem, because a malicious server can
> get a client to sign an auth message using any key the client holds,
> which it can then forward to another server and impersonate the
> client.

This is called a man-in-the-middle attack.  Passwords are vulnerable to
it (among many other active attacks).  ssh is carefully designed to
_not_ be vulnerable to it - well, except for first connect in cases
where the user incorrectly believes it's safe to trust the
peer-presented host key; those in situations where such risks are part
of the threat model should take care to not do that.  There might even
be a place for clients that don't support doing it at all.

> Still, a mechanism that allows the server to have the client act as
> an arbitrary signing oracle really doesn't seem like a good idea.

Then perhaps it's just as well ssh takes care to make sure it can't be
abused that way.  This is (part of) why client-chosen entropy and
server-chosen entropy are both mixed into the data signed during PK
auth: the server does not get to have the client sign arbitrary data.

> Fix the client, don't require all sorts of kludgery at the server.

Fortunately or unfortunately, that ship has sailed: ssh requires that
the server include support for this sort of behaviour by the client.
Of course, servers may choose to refuse service to clients that take
advantage of it, or can go out of their way to be obnoxious to clients
that try to use it (by lying, claiming that keys that cannot work might
work); as this thread demonstrates, such server behaviour is widely
considered problematic, even broken - and, I believe, with good cause.
I certainly know I'd file a bug report with the applicable vendor upon
encountering such behaviour (as I intend to with the vendor whose
server started this off - quite likely would have today except that
other issues blew up).

/~\ 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