Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenSSH: Dev

Too many public keys

 

 

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded


luto at amacapital

Apr 2, 2013, 3:57 PM

Post #1 of 12 (1212 views)
Permalink
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

Apr 2, 2013, 4:40 PM

Post #2 of 12 (1186 views)
Permalink
Re: Too many public keys [In reply to]

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

What should happen then?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


amesh at juniper

Apr 2, 2013, 5:01 PM

Post #3 of 12 (1181 views)
Permalink
Re: Too many public keys [In reply to]

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?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


carson at taltos

Apr 3, 2013, 2:17 AM

Post #4 of 12 (1170 views)
Permalink
Re: Too many public keys [In reply to]

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


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


luto at amacapital

Apr 3, 2013, 10:22 AM

Post #5 of 12 (1172 views)
Permalink
Re: Too many public keys [In reply to]

On Tue, Apr 2, 2013 at 5:01 PM, Arthur Mesh <amesh [at] juniper> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


aris at 0xbadc0de

Apr 5, 2013, 1:56 AM

Post #6 of 12 (1167 views)
Permalink
Re: Too many public keys [In reply to]

If you have too many public keys, you can use a config file to
specifically set an identity file to use with an host. I don't see what
problems you try to resolve, when in the opposite this limitation of
public key numbers tries per connection has actually been useful during
the Debian Openssl fiasco.
While I agree that there's no point counting failed gssapi attempts as
these cannot really be bruteforced.

Aris

Le 3/04/13 19:22, Andy Lutomirski a écrit :

> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


phil.pennock at globnix

Apr 5, 2013, 10:57 AM

Post #7 of 12 (1168 views)
Permalink
Re: Too many public keys [In reply to]

On 2013-04-05 at 10:56 +0200, Aris Adamantiadis wrote:
> If you have too many public keys, you can use a config file to
> specifically set an identity file to use with an host. I don't see what
> problems you try to resolve, when in the opposite this limitation of
> public key numbers tries per connection has actually been useful during
> the Debian Openssl fiasco.
> While I agree that there's no point counting failed gssapi attempts as
> these cannot really be bruteforced.

Throwing out a random crazy idea for consideration:

How about cap per keytype, then? If I'm trying to brute-force DSA,
trying an RSA key shouldn't count against that limit.

I suspect that a reasonable limit is 3 per key-type. Folks normally
have one per type loaded, they might try a second because they
forgot/didn't-know-about IdentitiesOnly, and one more allows for
weirdness, like "I added keys from a second host for an emergency, then
ran a tool which doesn't specify IdentitiesOnly".

Does this seem reasonable?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


aris at 0xbadc0de

Apr 5, 2013, 1:54 PM

Post #8 of 12 (1167 views)
Permalink
Re: Too many public keys [In reply to]

Le 5/04/13 19:57, Phil Pennock a écrit :

> How about cap per keytype, then? If I'm trying to brute-force DSA,
> trying an RSA key shouldn't count against that limit.
>
> I suspect that a reasonable limit is 3 per key-type. Folks normally
> have one per type loaded, they might try a second because they
> forgot/didn't-know-about IdentitiesOnly, and one more allows for
> weirdness, like "I added keys from a second host for an emergency, then
> ran a tool which doesn't specify IdentitiesOnly".
>
Hi Phil,

sorry but this doesn't make a lot of sense to me. Imho if you have more
than 3 keys, they're probably of the same type (if you swear by DSA
you're unlikely to have rsa keys) and you would run in the same problems
again.
Configuring your ssh client to use the appropriate key the first time
isn't harder than typing the good password the first time, and the limit
should instead show him that there's a problem.
Also there's a performance penalty because each pubkey try consumes one
RTT, this can be very significant if you have more than 3 keys on slow
links (3G). You cannot change this without making openssh incompatible
with the specifications or without an ugly hack.

Aris
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


cloos at jhcloos

Apr 5, 2013, 4:01 PM

Post #9 of 12 (1166 views)
Permalink
Re: Too many public keys [In reply to]

>>>>> "AA" == Aris Adamantiadis <aris [at] 0xbadc0de> writes:

AA> Configuring your ssh client to use the appropriate key the first time

The problem isn't the case where the remote site will accept one of one's
keys. That, as you wrote, it easy to configure.

The problem is when connecting to a site which does not provide an oob
way to install an authorized_keys file. Ssh(1) sends each key and the
remote sshd(8) drops the connection before one can enter one's passwd.

In practice, most times that occurs one intends to send an a_k file in
band, so using something like:

:; ssh -o PreferredAuthentications\ keyboard-interactive,password

is more convenient. Even if that means re-reading the man page yet
again or grep(1)ing around to remember what you called the shell
script or function you wrote the last time it hit you.... :-/

-JimC
--
James Cloos <cloos [at] jhcloos> OpenPGP: 1024D/ED7DAEA6
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


djm at mindrot

Apr 6, 2013, 7:17 PM

Post #10 of 12 (1164 views)
Permalink
Re: Too many public keys [In reply to]

On Fri, 5 Apr 2013, James Cloos wrote:

> >>>>> "AA" == Aris Adamantiadis <aris [at] 0xbadc0de> writes:
>
> AA> Configuring your ssh client to use the appropriate key the first time
>
> The problem isn't the case where the remote site will accept one of one's
> keys. That, as you wrote, it easy to configure.
>
> The problem is when connecting to a site which does not provide an oob
> way to install an authorized_keys file. Ssh(1) sends each key and the
> remote sshd(8) drops the connection before one can enter one's passwd.

ssh -i none user [at] hos
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


cloos at jhcloos

Apr 7, 2013, 4:45 AM

Post #11 of 12 (1172 views)
Permalink
Re: Too many public keys [In reply to]

>>>>> "DM" == Damien Miller <djm [at] mindrot> writes:

>> The problem is when connecting to a site which does not provide an oob
>> way to install an authorized_keys file. Ssh(1) sends each key and the
>> remote sshd(8) drops the connection before one can enter one's passwd.

DM> ssh -i none user [at] hos

That doesn't work here:

:; ssh -i none a-remote-site.org
Warning: Identity file none not accessible: No such file or directory.
Received disconnect from 62.xx.xxx.xx: 2: Too many authentication failures for cloos

ssh skips none because it is not found and then tries everything known
to the agent, just like w/o -i none.

-o PreferredAuthentications\ keyboard-interactive,password does work.

(It seems like there was something different I used to use, but the
above is what I've ended up with.)

-JimC
--
James Cloos <cloos [at] jhcloos> OpenPGP: 1024D/ED7DAEA6
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


djm at mindrot

Apr 8, 2013, 7:55 PM

Post #12 of 12 (1168 views)
Permalink
Re: Too many public keys [In reply to]

On Sun, 7 Apr 2013, James Cloos wrote:

> >>>>> "DM" == Damien Miller <djm [at] mindrot> writes:
>
> >> The problem is when connecting to a site which does not provide an oob
> >> way to install an authorized_keys file. Ssh(1) sends each key and the
> >> remote sshd(8) drops the connection before one can enter one's passwd.
>
> DM> ssh -i none user [at] hos
>
> That doesn't work here:
>
> :; ssh -i none a-remote-site.org
> Warning: Identity file none not accessible: No such file or directory.
> Received disconnect from 62.xx.xxx.xx: 2: Too many authentication failures for cloos
>
> ssh skips none because it is not found and then tries everything known
> to the agent

Sorry, if you are using the agent then

ssh -oIdentityFile=none -oIdentitiesOnly=yes user [at] hos

Seriously, if you have a ton of keys in the agent then it makes every
sense to limit what you present. In practice, it means filling out
~/.ssh/config:

Host a
IdentityFile ~/.ssh/id_host_a
Host b
IdentityFile ~/.ssh/id_host_b
Host c d e f g
IdentityFile ~/.ssh/id_host_lots
Host z
IdentityFile none
Host *
IdentitiesOnly yes

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.