I use Terminal in Mac to login remotely to various servers through SSH and been annoyed for quite sometimes by connecting to servers I maintained but getting rejected due to incorrect private ssh key. I maintained multiple keys under my .ssh local directory since I managed several project, project for works as well as for hobby. When we logged in using a private keys, ssh agent will try to remember that keys and tried the list of keys on upcoming login event. So if I maintain 10 private keys for different servers, it will silently try all the list of keys until it succeed. The only way to see by using DEBUG option (parameter “-vvvv”).
... debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /Users/Cyberheb/.ssh/google_compute_engine (0x7fda9b600b70), debug2: key: /Users/Cyberheb/.ssh/Project/Ooredoo/sufuser_tbd.qtel (0x7fda9b600bb0), debug2: key: /Users/Cyberheb/.ssh/Project/Ooredoo/hlrfe.qtel (0x0), explicit ...
Some server has restriction and protection against bruteforce (some cloud provider with centos having this policies), so if the server private keys is on my 10th in the list, the server will see an event that I tried to bruteforcing using 9 list of private keys and then blocked my IP due to that.
Fixing this issue is simple. As per ssh_config (ssh client config), ssh client will take precedence as below:
ssh(1) obtains configuration data from the following sources in the following order:
1. command-line options
2. user’s configuration file (~/.ssh/config)
3. system-wide configuration file (/etc/ssh/ssh_config)
So we can create a file called config under $HOME/.ssh, having values like below:
Host nds*tbd* IdentityFile ~/.ssh/Project/Ooredoo/sufuser_tbd.qtel IdentitiesOnly yes Host hlrfetbd* IdentityFile ~/.ssh/Project/Ooredoo/hlrfe.qtel IdentitiesOnly yes Host nds*apc* IdentityFile ~/.ssh/Project/Ooredoo/sufuser.qtel IdentitiesOnly yes
Another good thing using ssh config is a wild character, so we don’t have to maintain all the hosts in the file, we can simply use pattern name of the host and define which IdentityFile to use. BUT, we also have to define the value of IdentitiesOnly to yes. Otherwise, the similar situation will occurred again, ssh agent will maintain a list of private keys and tried to bruteforce the server. By defining IdentitiesOnly to yes, ssh client will only use specific private key to login to specific (or list of servers based on its defined pattern) server, thus avoiding another private keys to test.
I’ve seen similar issue becoming a root of problem to more application such as git client, any application which uses ssh keys as its authentication. The server simply refused ssh even though we already define specifically in command line which keys to use because it silently bruteforcing the server with other list of keys.