SSH - Known Hosts and StrictHostKeyChecking

This assumes you are familiar with making an SSH connection to an SSH server. These examples are based on Linux.

Regardless if you are using a password or a public / private key pair for authentication, when attempting to make an SSH connection to a target server, if the public certificate of the SSH server ( in this example) is not listed in the /etc/ssh/ssh_known_hosts or /home/username/.ssh/known_hosts file on the client, a prompt will appear stating The authenticity of host 'hostname (ip address)' can't be established. If you are certain you are connecting to a trusted SSH server.

~]# ssh
The authenticity of host 'server1 (' can't be established
DSA key fingerprint is BB37 83F2 5E3A 7A4C 6C84  F047 D97B DD4E 38BB 2082
Are you sure you want to continue connecting (yes/no)?


Typing no should return the following.

Host key verification failed


Typing yes should return the following. This will append the SSH servers public certificate to the /home/username/.ssh/known_hosts file on the client.

Warning: Permanently added 'server1' (DSA) to the list of known hosts.


Or, you could use the -o StrictHostKeyChecking=no to suppress the warning. This will append the SSH servers public certificate to the /home/username/.ssh/known_hosts file on the client.

ssh -o StrictHostKeyChecking=no


Or, you could use the ssh-keyscan command to get the public certificates from the target server and append the certificates to your known_hosts file.

ssh-keyscan >> $HOME/.ssh/known_hosts


The prior message means that the public certificate of the SSH server was added to the /home/username/.ssh/known_hosts file on the client. The /home/username/.ssh/known_hosts file will contain the hostname and public certificate of the SSH server.

~]# cat /home/username/.ssh/known_hosts
server1 dsa-sha2-nistp256 AAAAASKVndklvjMAPALKJnasdasldfkjaAAODHFAKa=


Once the public certificate of the SSH server has been added to /home/username/.ssh/known_hosts, the next time you connect to the SSH server, the prior prompts will no longer appear, because the client now trusts the SSH server. Or, more specifically, in the SSH connection, the client will send the public certificate to the SSH server. As long as the SSH server still has the private key that is matematically related to the public certificate, the connection will be considered trusted. This can be seen using the -v (verbose) flag.

~]# ssh -v
Server host key: 
Host '' is known and matches the ECDSA host key.
Found key in /home/username/.ssh/known_hosts
ssh_ecdsa_verify: signature correct


When there are numerous users on the client machine that will be connecting to the SSH server, it is preferable to add public certificate to the /etc/ssh/ssh_known_hosts file. The /etc/ssh/ssh_known_hosts file is a system-wide file that applies to all users on the system. The paste command can be used to copy the contents of the /home/username/.ssh/known_hosts file into the /etc/ssh/ssh_known_hosts file. 

~]# paste -s -d '\N' /home/username/.ssh/known_hosts >> /etc/ssh/ssh_known_hosts
server1 dsa-sha2-nistp256 AAAAASKVndklvjMAPALKJnasdasldfkjaAAODHFAKa=


Add a Comment

We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.

Please enter 24cf1 in the box below so that we can be sure you are a human.


Web design by yours truely - me, myself, and I   |   |