Working With known_hosts

Whenever you connect to a remote host, the SSH server on the remote host provides a public key. You can use this key to validate that you're connecting to the same host in the future to prevent Man-In-The-Middle (MITM) attacks. On the server side, this public key is stored as part of the HostKey pair. On the client system, the known_hosts database stores the public key for the host in the file $HOME/.ssh/known_hosts.

SSH Host key fingerprints from remote systems

When you connect to a remote system and the known_hosts database doesn't contain a key, the client prompts you to accept the fingerprint for the key. For example:

The authenticity of host 'server1.example.com (198.51.100.172)' can't be established.
ED25519 key fingerprint is SHA256:i45KP8BeY5c6nO87hjUrqo1fXsGgQkCpA5dHchXBWbk.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you accept the fingerprint, the $HOME/.ssh/known_hosts file stores the public key on the client system and you're no longer prompted every time you connect.

Listing key fingerprints in local known_hosts

You can list the fingerprints for keys stored in the known_hosts database by running:

ssh-keygen -l -f $HOME/.ssh/known_hosts

StrictHostKeyChecking

If the OpenSSH client has the StrictHostKeyChecking option set by default and the public key returned by the server changes, you're unable to connect to the remote server and a warning is displayed:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ED25519 host key for server1.example.com has changed,
and the key for the corresponding IP address 198.51.100.172
is unchanged. 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.
Offending key for IP in /home/user/.ssh/known_hosts:20
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ED25519 key sent by the remote host is
SHA256:qMBpuwP/LXLV8F5awaYtbXHO8v7LrqyY2BwVZk7tDxY.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:125
ED25519 host key for server1.example.com has changed and you have requested strict checking.
Host key verification failed.

Host keys don't change, so when you see this warning, you might not be connecting to the same system that you have connected to before. However, the key can be different for a legitimate reason, such as if the remote system is reinstalled, the OpenSSH Server keys are regenerated, or the domain name entry or IP address is reassigned to a new system. In such cases, you might want to remove any existing record of the system in the known_hosts database.

Removing an existing key

If you're certain that you can trust a new key provided by a remote server, you can remove an existing key from the known_hosts database by running:

ssh-keygen -R server1.example.com

Disabling StrictHostKeyChecking

In test environments, where servers are constantly reinstalled or replaced, you might want to disable StrictHostKeyChecking for particular hosts. You can disable host key checking when you connect to a remote system as follows:

ssh -o StrictHostKeyChecking=no user@server1.example.com

If you need to constantly disable strict host checking, consider adding this option to a host entry in the client configuration. See Setting SSH Client Configuration Options For a Host for more information.

Strict host key checking is enabled by default to prevent Man-In-The-Middle (MITM) attacks, so disabling that functionality isn't considered good security practice and isn't recommended on production systems.