4 Reasons Why SSH Connections Fail

as devops or it professionals, people may ask us why they can’t ssh to servers. it happens from time to time. not much fun. just routine work.

want to ease the pain and burden? let’s examine common ssh failures together.

share this link with others who might find it useful. they may be able to identify the root cause all by themselves or be efficient in collecting all necessary information before turning to us.

it’s not something fancy or difficult. just not everyone possesses enough information or experience about this. as devopsers, we shouldn’t stand in the way for any process. let’s empower people with a simple and easy guide.

here are four common ssh failures sorted by frequency.

1. our ssh public key is not injected to servers

ssh by password is very dangerous. nowadays, almost all serious servers will only accept ssh by a key file. here is the process:

• we generate an ssh key pair (even better, protect the private key with a passphrase ).
• send our ssh public key to the person who manages the servers.
• this person will inject our ssh public key there (usually, it’s ~/.ssh/authorized_keys ).
• then, we should be able to ssh.

here comes the most frequent ssh failure!

denny@laptop:/# ssh root@www.dennyzhang.com
permission denied (publickey).

this error message may have two possible clauses:

1. the private key doesn’t have the privilege to log in. either the public key is not injected correctly or simply it’s missing.
   
   note: if your ops/devops are not available, you can try alternatives. think about who else in the team can ssh. in fact, anyone who can ssh is able to perform the change.
2. the local ssh public key and private key are not correctly paired.

before connecting, the ssh will check whether our public key and private key are correctly paired. if not, it will reject to use the private key silently. yes, silently!

you may wonder how this could happen. as humans, we don’t let it happen, but we may have some automation scripts that create the mess. (btw, if we only have a valid private key without a public key, it’s fine.)

2. firewall prevents us from connecting

for security concerns, people may enforce a strict firewall policy. it means only certain ips can ssh.

denny@laptop:/# ssh root@www.dennyzhang.com
ssh: connect to host www.dennyzhang.com port 22: connection refused

# confirm with telnet. usually it shall connect in seconds
denny@laptop:/# telnet www.dennyzhang.com
trying 104.237.149.124...

you may want to fetch help immediately. just wait a second.

people may have reconfigured sshd to listen on other ports. are you sure it’s port 22? even better, double check the server ip and dns name.

i know they might be stupid questions, but people make these mistakes sometimes.

once it’s confirmed, talk to your devops. there is another possible reason for this failure: shhd is not up and running. very rare, i would say, but this could be it. in that case, devops and ops need to take actions immediately.

3. host key check fails

when you see the below warning for the first time, you may get confused. to be simple, it helps us to avoid the attack of the man in the middle.

denny@laptop:/# ssh root@www.dennyzhang.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       warning: possible dns spoofing detected!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
the ecdsa host key for [www.dennyzhang.com]:22 has changed,
and the key for the corresponding ip address [45.33.87.74]:22
is unknown. this could either mean that
dns spoofing is happening or the ip address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    warning: remote host identification has changed!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
it is possible that someone is doing something nasty!
someone could be eavesdropping on you right now (man-in-the-middle attack)!
it is also possible that a host key has just been changed.
the fingerprint for the ecdsa key sent by the remote host is
37:df:b3:af:54:a3:57:05:aa:32:65:fc:a8:e7:f9:3a.
please contact your system administrator.
add correct host key in /root/.ssh/known_hosts to get rid of this message.
offending ecdsa key in /root/.ssh/known_hosts:2
  remove with: ssh-keygen -f "/root/.ssh/known_hosts" -r [www.dennyzhang.com]:22
ecdsa host key for [www.dennyzhang.com]:22 has changed and you have requested strict checking.
host key verification failed.

each server can have a fingerprint. if the server is re-provisioned or it's simply a different server, the fingerprint would be different. once we have successfully logged in, our laptop will save the server’s fingerprint locally. next time we log in, it will do a comparison first. if the fingerprint doesn’t match, we will see the warning.

if we’re confident it has been re-provisioned recently, we can ignore this warning. remove the entry from ~/.ssh/known_hosts , or you can empty the file. you can even turn off the ssh host key checking for all hosts (certainly, i would not recommend this).

4. your ssh key file mode issues

as a self-protection, the file access of your ssh key file can’t be widely open. the file mode should be either 0600 or 0400.

denny@laptop:/# ssh -i id_rsa root@www.dennyzhang.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         warning: unprotected private key file!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
permissions 0644 for 'id_rsa' are too open.
it is required that your private key files are not accessible by others.
this private key will be ignored.
bad permissions: ignore key: id_rsa
permission denied (publickey).

use -v for verbose output: ssh -v $user@$server_ip .

original article here.