SSH: Host Key Verification Failed

You try to SSH in and get blocked, often with a big banner:

@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@
...
Host key verification failed.

Don't reflexively bypass this — it's a genuine security check. The first time you connect to a server, SSH records its unique host key in ~/.ssh/known_hosts. On every later connection it checks the key still matches. This error means the key the server presented doesn't match the one you saved. SSH stops because, in the worst case, that's what a man-in-the-middle attack looks like.

Step 1: Decide if the change is expected

Ask why the key would differ. Legitimate reasons:

• The server was rebuilt / reinstalled (new OS, new key).
• A cloud IP was recycled — same address, different machine.
• You're connecting through a new load balancer or bastion.

If none of those apply and nothing changed, be cautious — treat it as a real warning and verify the server through another channel before proceeding.

Step 2: If it's expected, remove the stale key

When you know the server legitimately changed, delete the old entry for that host. SSH usually prints the exact line number, but the clean way is by hostname:

ssh-keygen -R your-server.com        # or the IP you connect to

Next connect, SSH sees no saved key, asks you to trust the new one, and stores it.

Step 3: Reconnect and confirm the new key

ssh [email protected]
# The authenticity of host ... can't be established.
# ED25519 key fingerprint is SHA256:...
# Are you sure you want to continue connecting (yes/no)?

If you can, compare that fingerprint against one you got from the server's provider before typing yes.

This warning is SSH protecting you, not malfunctioning. Only clear the known_hosts entry once you can explain why the key changed — a rebuild, yes; an unexplained change on a stable server, investigate.

The checklist

1. The server's host key no longer matches your saved one.
2. Ask why: rebuilt server or recycled IP = expected; nothing changed = suspicious.
3. Expected? ssh-keygen -R <host> to drop the old key, then reconnect.
4. Verify the new fingerprint before trusting it if you can.