Black Friday Deals for Linux Users are Now Live!
Learn more
Sep 26, 2022 5 min read

Everything You Important You Should Know About the known_hosts file in Linux

Table of Contents

If you look into the .ssh folder in your home directory, you'll see a known_hosts file among other files.

[email protected]:~$ ls -l .ssh
total 16
-rwxr-xr-x 1 abhishek abhishek  618 Aug 30 16:52 config
-rw------- 1 abhishek abhishek 1766 Nov 12  2017 id_rsa
-rw-r--r-- 1 abhishek abhishek  398 Nov 12  2017 id_rsa.pub
-rw------- 1 abhishek abhishek    1 Sep 26 15:00 known_hosts

Here, id_rsa is your private SSH key, id_rsa.pub is the public SSH key. The config file in SSH is used for creating profiles to connect easily to various hosts. It is not a common file and I have created it specifically.

The focus of this article is on the last file, known_hosts. This ~/.ssh/known_hosts file is a vital part of client SSH configuration files.

Let me share more details on it.

What is the known_hosts file in SSH?

The known_hosts file stores the public keys of the hosts accessed by a user. This is a very important file that assures that the user is connecting to a legitimate server by saving its identity to your local system. It also helps in avoiding the man-in-the-middle attacks.

When you connect to a new remote server via SSH, you are prompted whether you want to add the remote hosts to known_hosts file.

SSH known_hosts file

The message basically asked if you wanted to add the details of the remote system to your system.

The authenticity of host '194.195.118.85 (194.195.118.85)' can't be established.
ED25519 key fingerprint is SHA256:wF2qILJg7VbqEE4/zWmyMTSwy3ja7be1jTIg3WzmpeE.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you go with yes, the identity of the server is saved to your system.

Avoiding man in the middle attack

Man in the middle attack illustration

Imagine that you connect to a server regularly and have added it to the known_hosts file.

If there is a change in the public key of the remote server, your system will note this change thanks to the information stored in the known_hosts file. You'll be alerted immediately about this change:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for xyz remote host has changed,and the key for the corresponding IP address xxx.yy.xxx.yy 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
69:4e:bb:70:6a:64:e3:78:07:6f:b4:00:41:07:d8:9c.
Please contact your system administrator.
Add correct host key in /home/.ssh/known_hosts to get rid of this message.
Offending key in /home/.ssh/known_hosts:1
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.

In such a case, you can contact the remote server’s administrator prior to accepting this new key. In this way, you can ensure that the remote server or host has not been compromised.

Sometimes a server’s or host’s key is intentionally altered either by the administrator or due to re-installation of the server.

Whatever be the reason for this change, you will need to first delete the old key from the known_hosts file for reconnecting to the remote server. Next time when you connect to this server, the client host will create a new host key for this server.

Managing Multiple Authenticated Users

As mentioned earlier, once a client host successfully connects to a remote server, its known_hosts file is appended with the server’s public key.

Sometimes you want a server to be authenticated to multiple users without being prompted for server key verification. For example, you are running some sort of configuration management tool like Ansible and you don’t want the client host to ask for server key verification.

So, If you have multiple users, you can bypass the SSH interactive prompt using three ways:

  • Manually appending the public key of the server to the known_hosts file of each user.
  • Use a command-line option -o StrictHostKeyChecking=no with each client while accessing the server over SSH (not recommended)
  • Register all your hosts in a master or primary ssh_known_hosts file and then orchestrate this file to all the client hosts. Also, to make this work, the ssh-keyscan command can be used:
ssh-keyscan -H -t rsa ‘your-server-ip’ >> /etc/ssh/ssh_known_hosts

The below screenshot shows how to use the StrictHostKeyChecking=no option:

Bypassing Host Key Checking using the StrictHostKeyChecking=no switch

The first method of managing multiple users for authenticating a server is the most toilsome as compared to the other two.

Getting remote system details from the known_hosts file

This is not an easy and straightforward task.

Almost all Linux systems set HashKnownHosts parameter to Yes in the SSH config file. It is a security feature.

This means that the details in the known_hosts file are hashed. You can see random numbers but cannot make anything out of them.

[email protected]:~$ cat .ssh/known_hosts

|1|yWIW17YIg0wBRXJ8Ktt4mcfBqsk=|cFHOrZ8VEx0vdOjau2XQr/K7B/c= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFR293PJnDCj59XxfqYGctrMo60ZU5IOjACZZNRp9D6f
|1|Ta7hoH/az4O3l2dwfaKh8O2jitI=|WGU5TKhMA+2og1qMKE6kmynFNYo= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCmrxLW436AyBGyGCggl/j2qBCr782AVIvbiTEsWNBWLcWMKYAQpTdAXnaV4bBRqnk2NJg/60XDHKC2DF1tzx6ABWN/R6vcUAbulI9H1RUWpJ1AiDmFL84MvW2UukbpN5a6Lr+DvjclVqPxJRjQKr6Vy2K9oJgGKnHVcWSIHeAlW49kCCg5fIxF8stBTqJg0cRk6uxmcYVud1vh9a7SaZGK+jFZTB75RiHAVFuitHWpljecMxJRNYy/EhmmXrrvyU8pObVXlWlDd61uwExi4uEwNSY+Do7vR1y8svnt9mjTzzyM6MhT4sOcxWmNgdmw7bU/wPpie3dSjZMQeu2mQCSM7SG28dwjSyFPpanRsZKzkh0okAaCSItoNwl6zOf6dE3zt0s5EI6BPolhFAbT3NqmXRblxb7eV8rGEPf14iguHUkg6ZQr2OUdfeN1FYNMJ8Gb9RD159Mwjl4/jPIBdnXvt7zYct3XhPKm7Wxv4K/RWZE837C7mGQh2KEahWajdq8=
|1|NonAy25kVXL24U2mx6ZNxAY5m98=|ypf0IMpf3qq3vhrvUMprssOhODs= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE3br/9jaZfdB+qBxiVEZBJMb4XQONwzV4tH1xeFZX/zkyws2eBHrVO9O5l9b6M6+gO6nBtCwAzzaeLOn6mo8GQ=

You can get the related entries from the known_hosts if you know the hostname or the IP address of the system:

ssh-keygen -l -F <server-IP-or-hostname>

But if you want a single command that could list all the servers and their details in clear text, that's not possible.

There are specially crafted tools and scripts used for deciphering the known_hosts but that's not in the scope for a regular user like you and me.

Remove an entry from the known_hosts

If you want to remove a specific entry from the known_hosts file, you can do so if you know the hostname or IP of the remote system.

ssh-keygen -R server-hostname-or-IP

This is much better than identifying the entries related to a server and then manually removing them using the rm command.

Conclusion

You have a better hold of system security with proper knowledge of various SSH configuration files. ‘Known_hosts’ is a vital part of these files.

I have only covered the known_hosts file here; if you’d like to explore more about SSH, look at our Getting Started With SSH in Linux guide.

Linux Foundation Training
Team LHB
Team LHB indicates the effort of a single or multiple members of the core Linux Handbook team.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Linux Handbook.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.