Understand known_hosts

~/.ssh/known_hosts is your memory of which server owns which key. After you verified the fingerprint in the previous lesson, SSH wrote one line in there. From now on a different key for that host is a loud security event, and that is what makes the file valuable.

Look at what got stored:

ssh-keygen -F 203.0.113.10

# Host 203.0.113.10 found: line 14 
203.0.113.10 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGx8...

-F finds the entry for a host. On many systems the hostname is stored hashed, so you cannot read the file with grep. ssh-keygen -F still works, and ssh-keygen -H hashes an existing plain file if you want that everywhere.

When the key changes

Destroy your disposable server and create a new one at the same IP. The new machine generates a fresh host key on first boot. Connect again:

ssh [email protected]

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Offending ED25519 key in /Users/flavio/.ssh/known_hosts:14
Host key verification failed.

Here you know why the key changed, because you rebuilt the server yourself. In real life you often do not. The same warning appears when DNS now points at a different machine, or when someone is intercepting the connection. So the first step is never “make the warning go away”. The first step is “why did this change?”.

Repair only the one entry

The lazy fix is deleting the whole known_hosts file. It works, and it also throws away every verified host you have ever connected to. Now every server is a stranger again and you are back to typing yes at prompts.

Remove just the entry for this host instead:

ssh-keygen -R 203.0.113.10

# Host 203.0.113.10 found: line 14
/Users/flavio/.ssh/known_hosts updated.
Original contents retained as /Users/flavio/.ssh/known_hosts.old

Then connect again and verify the new fingerprint against the console, exactly as you did the first time. You get a fresh prompt, you paste the fingerprint, and the new key is stored.

Notice what did not happen: you did not set StrictHostKeyChecking no, and you did not touch the other lines. Both shortcuts show up in tutorials, and both quietly turn the file from a security control into decoration.

Try this on your own: before running ssh-keygen -R, run ssh-keygen -F and save its output. After the repair, run -F again. The old and new public keys should differ, and only that one host should have changed.