TopolearnHost key checking is what stops a man-in-the-middle from impersonating your server.
Each SSH server has a host key pair, generated at install time (/etc/ssh/ssh_host_ed25519_key and friends). When you connect, the server proves it holds the private host key.
The first time, your client has nothing to compare with, so it asks:
The authenticity of host 'server (203.0.113.10)' can't be established. ED25519 key fingerprint is SHA256:...
Typing yes stores the key in ~/.ssh/known_hosts. Ideally you verify the fingerprint first, comparing it with the output of ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub run on the server (or with what your cloud console shows).
On later connections, ssh checks the presented key against known_hosts. If it differs you get WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! and the connection is refused. This is either a reinstalled server or an attack. Only after confirming the server really was rebuilt, remove the old entry with ssh-keygen -R hostname and connect again.
Useful settings: StrictHostKeyChecking accept-new automatically accepts keys for new hosts but still refuses changed ones, a sensible choice for automation. Never use StrictHostKeyChecking no with UserKnownHostsFile /dev/null outside throwaway test environments; it disables the protection entirely.
Example
# on the server: show its host key fingerprint
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# 256 SHA256:Xr3...9kQ root@server (ED25519)
# on the client
ssh-keygen -F server.example.com # is it in known_hosts?
ssh-keygen -R server.example.com # forget a (legitimately) changed key
ssh -o StrictHostKeyChecking=accept-new ci@server.example.comRemember
- known_hosts pins each server's host key
- Verify the fingerprint on first connect when it matters
- accept-new trusts new hosts but still rejects changed keys
Watch out for
- Reflexively deleting the known_hosts entry on a host-key warning without checking why the key changed.