Audit SSH configurations: HashKnownHosts option

How it works

Each time the SSH client connects with a server, it will store a related signature (a key) of the server. This information is stored in a file names named known_hosts. The known_hosts file itself is available in the .ssh subdirectory of the related user (on the client). In the case the signature of the server changes, SSH will protect the user by notifying about this chance.

Risk involved

This configuration option is very useful, but also introduces a new risk. Previously it was common to store the hostname related with the key. The result is a “picture” of the network, revealing which systems are connected. This made it easy for worms and other malicious scripts to use this information and spread to other systems, once they had a single system compromised.

Improve security

To reduce the risk of storing a clear picture of the network, the solution introduced was hashing the hostname. To enable this functionality, the HashKnownHosts option can be set to yes. This option can be found in the system-wide SSH client configuration file, which is usually /etc/ssh/ssh_config.

The final result of hashing entries will look something like this:

The hostname (hashed with ecdsa-sha2-nistp256) is unreadable for the human eye or malicious scripts. For each new connection to the related host, the hashing algorithm will result in the same string. This way the client knows it already has a stored key and compare it during the handshaking process with the server.


Small picture of Michael Boelen

This article has been written by our Linux security expert Michael Boelen. With focus on creating high-quality articles and relevant examples, he wants to improve the field of Linux security. No more web full of copy-pasted blog posts.

Discovered outdated information or have a question? Share your thoughts. Thanks for your contribution.

Mastodon icon