openssh unix dev - Apr 2013 - Too many public keys

Apparently my ssh agent is feeling energetic today:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [... (this is the only remotely sensible try)]
Received disconnect from [a.b.c.d]: 2: Too many authentication
failures for [username]

The client is 6.1p1 and the server is 5.9p1.

The web is full of workarounds (IdentitiesOnly, SSH_AUTH_SOCK=, etc),
but I think this is silly.  This IMO shouldn't happen and, if it does,
the error message should give a better clue of what's wrong.

--Andy

Andy Lutomirski wrote:
> Apparently my ssh agent is feeling energetic today:
..
> This IMO shouldn't happen
What should happen then?


//Peter

On Tue, Apr 02, 2013 at 03:57:15PM -0700, Andy Lutomirski
wrote:
> Received disconnect from [a.b.c.d]: 2: Too many authentication
> failures for [username]
Would it make sense to split max_authtries in to two separate counters:
 1) one that counts password/kbd_interactive auth attempts
 2) one that counts pubkey/certs auth attempts

One could argue password/kbd_interactive authentication attempts are
much more interesting. Having a low DEFAULT_AUTH_FAIL_MAX for these
would make sense.

Whereas, pubkey/cert auth attempts could have a higher threshold. This
would allow people who have boatload of different keys to avoid this
problem.

Thoughts?

On 4/3/13 1:01 AM, Arthur Mesh wrote:
> On Tue, Apr 02, 2013 at 03:57:15PM -0700, Andy Lutomirski wrote:
>> Received disconnect from [a.b.c.d]: 2: Too many authentication
>> failures for [username]
>
> Would it make sense to split max_authtries in to two separate counters:
>   1) one that counts password/kbd_interactive auth attempts
>   2) one that counts pubkey/certs auth attempts
>
> One could argue password/kbd_interactive authentication attempts are
> much more interesting. Having a low DEFAULT_AUTH_FAIL_MAX for these
> would make sense.
>
> Whereas, pubkey/cert auth attempts could have a higher threshold. This
> would allow people who have boatload of different keys to avoid this
> problem.
I have also seen this where GSSAPI auth eats into the auth count and 
causes spurious failures. I concur that a different threshold for 
password-like auth mechanisms would be a useful feature.

-- 
Carson

On Tue, Apr 2, 2013 at 5:01 PM, Arthur Mesh <amesh at juniper.net>
wrote:
> On Tue, Apr 02, 2013 at 03:57:15PM -0700, Andy Lutomirski wrote:
>> Received disconnect from [a.b.c.d]: 2: Too many authentication
>> failures for [username]
>
> Would it make sense to split max_authtries in to two separate counters:
>  1) one that counts password/kbd_interactive auth attempts
>  2) one that counts pubkey/certs auth attempts
>
> One could argue password/kbd_interactive authentication attempts are
> much more interesting. Having a low DEFAULT_AUTH_FAIL_MAX for these
> would make sense.
>
> Whereas, pubkey/cert auth attempts could have a higher threshold. This
> would allow people who have boatload of different keys to avoid this
> problem.
That would work for me.

I wonder if (with a protocol extension) something even better could be
done: take all locally available private keys, construct a small Bloom
filter and send it to the server, and have the server decide whether
any of the keys it accepts match.  (This would be efficient for shell
accounts but would be worse than useless for things like gitolite.)

--Andy