SSH host key verification failed, explained and fixed

SSH remembers each server's public key in the ~/.ssh/known_hosts file the first time you connect. On later connections it compares. This error, in its loud form headed “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”, means the key the server presented now is different from the one on file. OpenSSH then refuses to connect, by design: a changed key can mean the server was rebuilt, or it can mean someone is intercepting the connection. The fix is to establish which of those it is, then update the stored key deliberately, never reflexively.

Establish whether the change is legitimate

  1. Ask what changed: a server reinstall, a rebuilt virtual machine, a replaced host, an IP address reassigned to a different machine, or a cluster/failover address all legitimately change the key. If the server's administrator (or you, an hour ago) did one of these, the warning is expected.
  2. Verify the new fingerprint through an independent channel: the server's console (cloud provider console, IPMI, physical screen) can display it with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Compare it character for character with the fingerprint the warning prints. This out-of-band check is what makes updating the key safe rather than hopeful.
  3. If nothing explains the change and the fingerprint cannot be verified, stop. Do not connect and do not enter credentials; investigate through the provider or administrator first. This is the one SSH error where proceeding “to see if it works” defeats the protection entirely.

Update the stored key (once verified)

  1. Remove the stale entry by hostname or IP: ssh-keygen -R server.example.com (and again for the IP if you connect by address; the warning names the offending line and host). This edits known_hosts precisely instead of hand-deleting lines.
  2. Reconnect and confirm the fingerprint shown matches the one verified out-of-band before accepting it. The new key is then stored and future connections are silent again.
  3. For fleets rebuilt often (test servers, cloud instances), per-host exceptions exist (StrictHostKeyChecking accept-new for a specific host in ~/.ssh/config); weakening the check globally for all hosts removes the protection everywhere and is the wrong trade.

Common questions

Why does this appear after the server was reinstalled? Host keys are generated at install time. A reinstall creates a new key pair, so from SSH's perspective the server's identity changed, which is indistinguishable from an interception until a human verifies it, hence the alarm and the manual reset.

I connect by IP and by hostname and fixed only one, why does it still warn? known_hosts stores entries per name or address as connected. Re-run ssh-keygen -R for each form you use, or connect consistently by one name.

Is deleting the whole known_hosts file a good shortcut? It works but throws away every verified key you have accumulated, and the next connection to any server becomes trust-on-first-use again. Removing the single stale entry with ssh-keygen -R is the same effort with none of the loss.

Related errors

Permission denied (publickey) · SSH: Connection refused · Permission denied (Linux)