If you're using ssh
and authenticating your connections with certificates, you can use a different certificate for each connection. This is very useful if you want to keep everything separate, but it won't be long before you try to log into a machine using:
ssh user@<ip address>
and you get an error like:
Received disconnect from <ip address> port 22:2: Too many authentication failures
Disconnected from <ip address> port 22
How can you fix this?
If you use the -v
(verbose) parameter, you'll be able to see that all of the certificates on your system are used in turn to try to authenticate the connection. If the correct certificate is too far down the list, you'll see that the "Too many authentication failures
" error is returned by the remote server before it can be used.
If you decide to specify the certificate file in the command line, like this:
ssh -i /path/to/certificate user@<ip address>
You might be surprised to see you still get the "Too many authentication failures
" error. This is because it's the expected behaviour of ssh
, as you can see in the man page for ssh_config:
IdentityFile
Specifies a file from which the user's DSA, ECDSA, authenticator-hosted ECDSA, Ed25519, authen‐
ticator-hosted Ed25519 or RSA authentication identity is read. You can also specify a public
key file to use the corresponding private key that is loaded in ssh-agent(1) when the private
key file is not present locally. The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa. Additionally,
any identities represented by the authentication agent will be used for authentication unless
IdentitiesOnly is set. If no certificates have been explicitly specified by CertificateFile,
ssh(1) will try to load certificate information from the filename obtained by appending
-cert.pub to the path of a specified IdentityFile.
...
It is possible to have multiple identity files specified in configuration files; all these iden‐
tities will be tried in sequence. Multiple IdentityFile directives will add to the list of
identities tried (this behaviour differs from that of other configuration directives).
In short, ssh
will try all of the default and configured certificates, and then try the one specified by the -i
parameter after those. So, this won't fix the problem.
The way to fix the problem is to update the ssh configuration file, to force the use of the identities file.
Open .ssh/config
for editing, and do one, or both, of the following:
If you want to specify that specific hosts use only the identity file specified for that host, add the following to the Hosts
block for that host:
IdentitiesOnly yes
e.g.:
Host mydomain.com
IdentityFile /path/to/my/key
IdentitiesOnly yes
If you want the behaviour of the specified hosts to remain unchanged, just add the following to the end of the .ssh/config
file:
Host *
IdentitiesOnly yes
RSAAuthentication no
Once you've done this, save the file and try the ssh
command again. This time you should get a connection.