SSH known_hosts: Add, Remove, and Verify Host Keys (2026)

When you SSH into a new server for the first time, your client (e.g., ssh on your laptop) asks if you trust the server’s identity. It’s like meeting someone new and them asking you to remember their face. Your SSH client stores this "face" – the server’s public host key – in a file called ~/.ssh/known_hosts. The next time you connect, it checks if the face it sees matches the one it remembers. If it doesn’t, you get a scary warning about potential man-in-the-middle attacks, and by default, SSH refuses to connect.

Let’s see this in action. Imagine you’re SSHing into server.example.com for the first time.

ssh user@server.example.com

You’ll see something like this:

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

If you type yes, the server’s public key gets added to your ~/.ssh/known_hosts file. You can peek at it:

cat ~/.ssh/known_hosts

It will look something like this (the exact format depends on your SSH client version and key type):

server.example.com,192.168.1.100 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbG5zd...

This line contains the hostname/IP, and the server’s public key.

Now, if you try to SSH again, you won’t get that prompt. The client silently verifies the key. If the server’s key changes (e.g., the server was reinstalled, or worse, someone is trying to impersonate it), you’ll get a critical warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd
Please contact your system administrator.
...

This is the core problem known_hosts solves: preventing you from connecting to a fake server without realizing it. It’s a trust anchor.

There are a few ways to manage this file.

Adding a Host Key Manually (Pre-seeding)

Sometimes, for security or convenience, you want to add a server’s key before the first SSH connection. This is common in automated deployments or when setting up a new workstation.

Diagnosis: You don’t have the key yet. You’ll get the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message if you try to connect to a server whose key is different from what’s in known_hosts, but if it’s not there at all, you get the initial prompt.

Fix: Use ssh-keyscan. This command fetches the public key of a remote host.

ssh-keyscan server.example.com >> ~/.ssh/known_hosts

Why it works: ssh-keyscan performs a brief handshake with the SSH server to retrieve its public host key(s) and prints them to standard output. Appending (>>) this output to your ~/.ssh/known_hosts file pre-populates it. The next time you SSH, the client will find the key and verify it without prompting. You can specify key types: ssh-keyscan -t rsa,ecdsa,ed25519 server.example.com >> ~/.ssh/known_hosts.

Removing a Host Key

If a server’s key changes legitimately (e.g., the server was rebuilt), or if you simply want to remove an entry, you can do so.

Diagnosis: You’re seeing the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message and you know the key change was legitimate.

Fix: Use ssh-keygen -R.

ssh-keygen -R server.example.com

Why it works: This command scans your ~/.ssh/known_hosts file for any lines associated with server.example.com (by hostname or IP address) and removes them. The next time you connect, SSH will treat it as a new host and prompt you to verify its key, allowing you to add the new, legitimate key. You can also remove specific keys by providing the full hostname or IP: ssh-keygen -R 192.168.1.100.

Verifying a Host Key

You can verify the fingerprint of a host key without connecting or modifying your known_hosts file. This is crucial if you receive the "host key changed" warning and want to confirm the new key is legitimate.

Diagnosis: You received the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message and need to confirm the new key’s identity.

Fix: Use ssh-keygen -l with the -f flag to read from the SSH protocol stream.

ssh-keygen -lf <(ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -T user@server.example.com 2>&1 | sed -n 's/.*WARNING: REMOTE HOST IDENTIFICATION IS TO...//p')

Let’s break that down:

• ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -T user@server.example.com: This attempts a connection but disables strict host key checking and prevents it from using or modifying your actual known_hosts file. The -T flag disables pseudo-terminal allocation, which is often used for interactive sessions.
• 2>&1 | sed -n 's/.*WARNING: REMOTE HOST IDENTIFICATION IS TO...//p': This redirects standard error (where the key fingerprint is printed in this scenario) to standard output and uses sed to extract just the warning message that contains the fingerprint.
• ssh-keygen -lf <(...): This takes the output of the previous command (the fingerprint string) and uses ssh-keygen -l to display it in a human-readable format.

Alternatively, and often simpler if you have the fingerprint from a trusted source (like the server administrator’s email or a secure out-of-band channel), you can just compare it visually. The warning message itself displays the new fingerprint. You can then compare this to the old fingerprint that was previously in your known_hosts file.

# On your client machine, to see the key currently in known_hosts:
ssh-keygen -lf ~/.ssh/known_hosts | grep server.example.com

You then manually compare the output of the two commands.

The most common pitfall is blindly typing yes to the initial prompt or when a key changes, bypassing the security mechanism entirely. The known_hosts file is your guard against unauthorized access, and understanding how to manage it is key to secure remote administration.

If you fix a host key issue by removing and re-adding it, the next error you might encounter is a Permission denied (publickey,password) if your SSH keys aren’t set up correctly on the server itself.