Re: "too many auth failures"?

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

[Combining several replies to save space]

der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

>> Stepping back a bit, why are you sending *six* keys to the server?
>> 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?

Simon Josefsson <simon%josefsson.org@localhost> writes:

>Also, you could refuse to enter a PIN to get the key skipped...  You could
>specify what key to use...  You could specify to not use any keys. You could
>use an agent that gets the PIN.

You forgot the one that actually happens, based on extensive real-life
experience with S/MIME and SSL:

- The user bypasses the annoying security mechanisms in order to get on with
  their job and avoid all the crap that their (from their perspective) broken
  software is throwing at them.

James Cloos <cloos%jhcloos.com@localhost> writes:

>Ssh(1) will try the key specificed on the command line or in the config files
>for the specified remote host, if any.  Should that fail, it then tries every
>key in the agent in the order they were ssh-add(1)ed.

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?  That would
be like Firefox (see above) trying every stored password it knows for every
site in the hope that one works.  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.

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.  The only thing
preventing this is the exchange hash, which requires that either the malicious
server can create collisions with SHA-1 or that the target server is using a
poor RNG *cough*Debian*cough* so you can keep the exchange hash constant.
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.

>From the above it certainly looks to me like the client is badly broken.  Fix
the client, don't require all sorts of kludgery at the server.

Peter.