SSH aborts with Too many authentication failures

Question

I'm attempting to run this simple provisioning script but I'm encountering errors when running vagrant up and then vagrant provision commands.

I read that I needed to create a /etc/ansible/hosts file which I've done, populating it with:

[vagrant]
192.168.222.111

My SSH config (some details removed):

Host default
HostName 127.0.0.1
User vagrant
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile /Users/ashleyconnor/.vagrant.d/insecure_private_key
IdentitiesOnly yes
LogLevel FATAL

Host            server
HostName        XXX.XXX.XXX.XXX
User            ash
PreferredAuthentications publickey
IdentityFile    ~/.ssh/ash_ovh

Host            deployer
HostName        XXX.XXX.XXX.XXX
User            deployer
PreferredAuthentications publickey
IdentityFile    ~/.ssh/deployer_ovh

Host            bitbucket.org
PreferredAuthentications publickey
IdentityFile    ~/.ssh/bitbucket

Host            github.com
PreferredAuthentications publickey
IdentityFile    ~/.ssh/github

Host            staging
HostName        192.168.56.10
User            deployer
PreferredAuthentications publickey
IdentityFile    ~/.ssh/id_rsa

The SSH output I'm receiving seems to churn through all my keys:

<192.168.222.111> ESTABLISH CONNECTION FOR USER: vagrant
<192.168.222.111> REMOTE_MODULE setup
<192.168.222.111> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-o', 'ControlPersist=60s', '-o', 'ControlPath=/Users/ashleyconnor/.ansible/cp/ansible-ssh-%h-%p-%r', '-o', 'IdentityFile=/Users/ashleyconnor/.vagrant.d/insecure_private_key', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'User=vagrant', '-o', 'ConnectTimeout=10', '192.168.222.111', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061 && echo $HOME/.ansible/tmp/ansible-tmp-1394317116.44-226619545527061'"]
fatal: [192.168.222.111] => SSH encountered an unknown error. The output was:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/ashleyconnor/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/ashleyconnor/.ansible/cp/ansible-ssh-192.168.222.111-22-vagrant" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.222.111 [192.168.222.111] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug3: timeout: 10000 ms remain after connect
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/ashleyconnor/.vagrant.d/insecure_private_key" as a RSA1 public key
debug1: identity file /Users/ashleyconnor/.vagrant.d/insecure_private_key type -1
debug1: identity file /Users/ashleyconnor/.vagrant.d/insecure_private_key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.222.111" from file "/Users/ashleyconnor/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ashleyconnor/.ssh/known_hosts:20
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
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-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,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,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
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-ctr hmac-md5 zlib@openssh.com
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
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: 119/256
debug2: bits set: 527/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 50:db:75:ba:11:2f:43:c9:ab:14:40:6d:7f:a1:ee:e3
debug3: load_hostkeys: loading entries for host "192.168.222.111" from file "/Users/ashleyconnor/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/ashleyconnor/.ssh/known_hosts:20
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.222.111' is known and matches the RSA host key.
debug1: Found key in /Users/ashleyconnor/.ssh/known_hosts:20
debug2: bits set: 511/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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/ashleyconnor/.ssh/id_rsa (0x7fc212600540),
debug2: key: /Users/ashleyconnor/.ssh/bitbucket (0x7fc212600730),
debug2: key: /Users/ashleyconnor/.ssh/deployer (0x7fc212600a00),
debug2: key: /Users/ashleyconnor/.ssh/github (0x7fc212600c80),
debug2: key: /Users/ashleyconnor/.ssh/ash_ovh (0x7fc212601010),
debug2: key: /Users/ashleyconnor/.ssh/deployer_ovh (0x7fc2126011e0),
debug2: key: /Users/ashleyconnor/.vagrant.d/insecure_private_key (0x0), explicit
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,gssapi-keyex,hostbased,publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: ,gssapi-keyex,hostbased,publickey
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/bitbucket
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/deployer
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/github
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/ash_ovh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /Users/ashleyconnor/.ssh/deployer_ovh
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Received disconnect from 192.168.222.111: 2: Too many authentication failures for vagrant

The vagrant ssh command works fine.

Answer 1

According to an older* ssh-config(5) man page, ssh will always try all keys known by the agent in addition to any Identity Files:

 IdentitiesOnly

         Specifies that ssh(1) should only use the authentication identity files
         configured in the ssh_config files, even if ssh-agent(1) offers more
         identities.  The argument to this keyword must be “yes” or “no”.  This
         option is intended for situations where ssh-agent offers many different
         identities.  The default is “no”.


 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or RSA authentication
         identity is read.  The default is ~/.ssh/identity for protocol version 1,
         and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol
         version 2.  Additionally, any identities represented by the  
         authentication agent will be used for authentication.  ssh(1) will try
         to load certificate information from the filename obtained by
         appending -cert.pub to the path of a specified IdentityFile.

To prevent this, one must specify IdentitiesOnly=yes in addition to the explicitly provided private key.

For example, running the ssh command below:

$ ssh -i /home/henk/.vagrant.d/insecure_private_key \
  vagrant@192.168.222.111 echo ok

produces:

Received disconnect from 192.168.222.111: 2: Too many authentication 
failures for vagrant

However, running the same ssh command and, in addition, specifying IdentitiesOnly=yes:

$ ssh -o IdentitiesOnly=yes \
  -i /home/henk/.vagrant.d/insecure_private_key vagrant@192.168.222.111 echo ok

produces:

ok

* Note: The OpenBSD project hosts up to date docs for IdentitiesOnly and IdentityFile. These include extra text for new features that do not change the essence of this answer.

Answer 2

So I had 5 keys in my ssh-agent and despite the explicit option of using the vagrant ssh key it still insisted on looping through keys in my agent before reaching max_tries conveniently before getting to the right key.

To check you have this problem: Run ssh-add -l - if this list is > 5 you need to remove keys or disable the agent.

To fix: Run ssh-add -d ~/.ssh/X where X is the key you want to remove.

Answer 3

After I tried all advises here without success, I recognized that my problem was the new authentication method (GSSAPI), which was always unsuccessful.

I solved this by editing ~/.ssh/config file:

Host *
  GSSAPIAuthentication no

Hope this helps somebody too.

Answer 4

To prevent failure from trying too many keys, we can ssh using -o 'IdentitiesOnly=yes' e.g ssh -i privateKey -o 'IdentitiesOnly=yes' user@host

alternatively, we can add the following lines to ~/.ssh/config file

Host *
IdentitiesOnly yes

Answer 5

Semi-Related: PuTTY SSH Client

Problem

Example
I had this issue with with PuTTY (Windows 7) as my ssh client.

PuTTY Fatal Error  
Remote side sent disconnect message 
type 2 (protocol error):  
"Too many authentication failures"

For me it was because I was using Pageant authentication with an active Pageant server (KeePass/KeeAgent) running with no public keys yet placed on the SSH server. It seems like the 6 keys I had on the Pageant server were attempted even though the SSH server had not yet been configured for key authentication.
I realize that this is only slightly related to the original question, but I hope this helps any lost PuTTY users who stumble across this post like I did.

Solution

Image
My solution was to disable pageant authentication in putty under Connection>SSH>Auth>[N] Attempt authentication using Pageant.
Not having a Pageant server actively running should have the same effect.

Answer 6

My situation was similar to what Ashley goes over in their answer, however vagrant ssh was working correctly, but I was getting this error when using vagrant scp (it's an additional plugin for vagrant):

vagrant scp file default:
Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.
Received disconnect from 127.0.0.1 port 2222:2: Too many authentication failures for vagrant
Disconnected from 127.0.0.1 port 2222
lost connection

Running ssh-add -l showed I had quite a lot of keys configured in my ssh agent daemon (>10). The following solution worked for me, but please READ ON before you run this:

ssh-key -D
ssh-ley -A

This deletes all identities from your daemon, and then adds back all the ones it can detect, which in my case included all the identities I normally use and all the ones from vagrant. More info about this with man ssh-add of course. I was running this on Mac so I have OpenSSH_8.1p1, LibreSSL 2.7.3, check that your version supports -A before running ssh-key -D !

Answer 7

Your ssh-agent holds more keys than the ssh server allows authentication attempts ("MaxAuthTries", default: 6).

Note that some ssh-agents, in particular the GNOME Keyring, autoload all keys they find in ~/.ssh, and that these keys cannot be unloaded with "ssh-add -[dD]".

Here are some solutions:

• You have configured the correct key in your ~/.ssh/config already, so you don't need the agent. Make the client ignore the agent, e.g. unset SSH_AUTH_SOCK or use "IdentitiesOnly=yes" as @henk-langeveld suggested
• Move some keys out of ~/.ssh (a subdir like ~/.ssh/noauto works too) to prevent them from getting auto-loaded. You can still ssh-add them manually if you need them.
• Increase "MaxAuthTries" on the server side, the number of allowed authentication attempts

Answer 8

To connect server using quick fix command:

ssh -o IdentitiesOnly=yes -i ~/.ssh/private_key_or_pem_file_name server_user_name@ip_OR_hostname echo ok

Recommended Way is mentioned below:

But if you have capistrano receipes or other softwares which are connecting your ssh server then you have to fix in proper way as mentioned below:

In ~/.ssh/config file mention "IdentitiesOnly yes" option in your server configuration

Host server_domain_OR_ip server_name_your_choice
    User server_user_name
    Hostname server_domain_OR_ip
    RSAAuthentication yes
    Compression yes
    IdentityFile ~/.ssh/private_key_OR_pem_file
    IdentitiesOnly yes
    Port 22

private_key_OR_pem_file: In case of pem file mention extension too ".pem"

Answer 9

I ran into this same error while trying to run an ansible playbook. I ended up supplying the IdentitiesOnly ssh option using --ssh-extra-args :

ansible-playbook -i ../.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml --ssh-extra-args="-o IdentitiesOnly=yes"

Answer 10

For Windows+PuTTY realm:

1. Configure the session Connection -> SSH -> Auth -> Private key file for authentication. Obviously, you put there path to the private key in PuTTY format (.ppk). It can be password protected - if agent (pageant.exe or similar agent) is running, only the public part of the key is read and used to lookup the appropriate key in the agent, and you won't be asked for the password.

2. Furthermore, you can specify the public key in the aforementioned field: PuTTY or OpenSSH format (the one you put into authorized_keys)! It would still work and you don't ever need your private key on file system. For example, my private keys live in KeePass+KeeAgent and not stored anywhere on FS directly.

3. To troubleshoot, right click on the opened PuTTY session window title and check Event Log. If everything is setup properly, you should see something like below. Mind the last line, where PuTTY is able directly match the proper key from the agent, instead of trying one by one.

Reading key file "C:\user-ssh-key.ppk"
(optionally) Key file contains public key only
Pageant is running. Requesting keys.
Pageant has XX SSH-2 keys
Pageant key #X matches configured key file

Answer 11

Key message is

Received disconnect from 192.168.222.111: 2: 
    Too many authentication failures for vagrant

You copied the vagrant ssh-config output as the default host into .ssh/config but this is skipped because it has conflicting parameters (hostname, port). With no matching entry, ssh will just try all the keys it can find.

Test the ssh attempt again with the -i option

$ ssh -i $HOME/.vagrant.d/insecure_private_key vagrant@192.168.222.111 echo ok

I believe this is how you'd specify this in the Ansible Inventory:

[vagrant]
192.168.222.111 ansible_ssh_private_key_file=/.../.vagrant.d/insecure_private_key

Abbreviated the path for readability

---

Original answer:

Compare the output of vagrant ssh-config with the vagrant entry in your .ssh/config. Make sure the private key path is an exact match.

Also verify that the keyfile cannot be accessed by any other accounts. We all know what that key is, but SSH doesn't know this thing is public knowledge, and tries to protect us from using keys that may be compromised.