openssh public key auth broken if one has many keys but only in X11

[noah dain]

Binary package hint: openssh-client

After upgrading from 8.04 to 8.10, I could not log into any machines via ssh where I had already configured public-key auth. This happens with both rsa and dsa keys.

The error given was:
"Received disconnect from 10.0.0.1: 2: Too many authentication failures for <USER>"

`ssh -vvv <hostname>` showed that ssh client was trying keys randomly(?), even though ~/.ssh/config specified the key properly (and has always worked in the past).

workaround 1: If I remove all the keys from ~/.ssh/ except for the host I was trying, I could then log into that host successfully while in X11.
workaround 2: use ssh client directly from the console (with or without X11 running on anther vty)

$ apt-cache policy openssh-client
openssh-client:
  Installed: 1:5.1p1-3ubuntu1

Script started on Wed 17 Dec 2008 03:24:11 PM EST
[ndain@ganymede] [jobs:0] [exit:0] [cpu:44C] [15:24] [12/17/08] [~]
$ ssh -vvv io
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/ndain/.ssh/config
debug1: Applying options for io
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to io.jovian.local [10.0.0.1] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /<email address hidden>.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /<email address hidden> type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,<email address hidden>
debug2: kex_parse_kexinit: none,<email address hidden>
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 125/256
debug2: bits set: 512/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/ndain/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 21
debug1: Host 'io.jovian.local' is known and matches the RSA host key.
debug1: Found key in /home/ndain/.ssh/known_hosts:21
debug2: bits set: 482/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received

## this line is repeated once for every key (host0,host1,host2...):
debug2: key: <email address hidden> (0x7fe0c1d22a70)
## (excess snipped)

debug2: key: /<email address hidden> ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey

## here's where things get wonky:

debug1: Offering public key: <email address hidden>
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: <email address hidden>
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: <email address hidden>
debug3: send_pubkey_test
## (excess snipped)

## ssh keeps trying all the wrong keys until the server boots us:

Received disconnect from 10.0.0.1: 2: Too many authentication failures for ndain
[ndain@ganymede] [jobs:0] [exit:255] [cpu:44C] [15:24] [12/17/08] [~]
$ exit
Script done on Wed 17 Dec 2008 03:24:19 PM EST

[noah dain (noahdain)]

putty (0.60-3) fails with the same error (too many authentication errors).

putty is not configured at all on this machine so it should be in passwd auth mode. However, ss soon as I put in my login name it comes up with the error.

[noah dain (noahdain)]

workaround/fix:
- move all keys into subdirectories and update config to reflect changes.
- even with multiple keys in subdirectories it does not try the wrong keys.

hypothesis:
- the ssh client looks in ~/.ssh and tries any files it deems to be keys, even when 'config' is configured explicitly with the appropriate key. Fortunately, it does not recurse into subdirs.n

other observations:
- the behaviour persists without a config file and specifying the key on the command line (ie. ssh -i keyfile host)
- this fixes putty, also (must have been patched to use ~/.ssh at some time)

[Vitality (the-shade)]

unfortunately, I have the same bug (
Ubuntu 9.04.
 I've found an another workaround:
 - remove files with *.pub extension from ~.ssh folder

I don't have an idea, but may this issue is connected with seahorse agent?
Any help would be appreciated

[Nick Burch (nick-torchbox)]

Try setting "IdentitiesOnly yes" in your ssh config file. It seems that if you have lots of public keys, then by default on the newer ssh, the key agent will offer them all. Setting "IdentitiesOnly yes" will make ssh only go for the correct key, and not all of them!

(I had a similar problem, and this seemed to be the fix for me)

[Vitality (the-shade)]

Thank you Nick!
This works for me!!!

[Chuck Short (zulcss)]

Fixed according to user.

Regards
chuck