Linux · medium · Day-to-day operations

"Host key verification failed" / REMOTE HOST IDENTIFICATION HAS CHANGED

The server presented a different host key than the one recorded. SSH refuses to continue, which is the correct behaviour — the question is why it changed.

What you see

A large warning banner about a possible man-in-the-middle attack, naming the offending line in known_hosts. The connection is refused.

What is actually wrong

Usually benign — the server was rebuilt, restored from a snapshot, or the IP has been reassigned to a different machine. Occasionally it is exactly what the warning says.

Codes and articles

Host key verification failedREMOTE HOST IDENTIFICATION HAS CHANGEDPOSSIBLE DNS SPOOFINGknown_hosts

Fixes (2)

Verify the fingerprint before trusting it

Shell15 minuteslow riskreversible

You cannot account for the change. Do this before removing anything — the warning is doing its job.

Get the fingerprint the server is actually presenting.

Shell

ssh-keyscan -t ed25519 server.example.com 2>/dev/null | ssh-keygen -lf -

Get the real fingerprint from the server itself, through a channel that is not SSH — a console, a cloud provider's serial output, or a colleague standing at it.
Shell
```
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
```
Comparing the presented fingerprint against one you fetched over the same suspect connection proves nothing. It has to come from somewhere else.
If they match, the change is legitimate — proceed to remove the old entry.
If they do not match, stop. Do not connect, do not type a password, and investigate the network path.

Confirm it workedThe two fingerprints, obtained independently, are identical.

If you need to undo itNone — this is a verification step.

Remove the stale entry

Shell on the client5 minuteslow riskreversible

The change is accounted for and, ideally, the fingerprint has been verified.

Remove just that host's entry rather than emptying the file.
Shell
```
ssh-keygen -R server.example.comssh-keygen -R 10.0.0.50
```
Deleting the whole known_hosts file throws away every other server's identity too, and leaves you unable to detect a real problem next time.
If the warning names a line number, that is the entry — confirm it is gone.
Shell
```
grep -n 'server.example.com' ~/.ssh/known_hosts
```
Reconnect and check the fingerprint you are being asked to accept matches what you verified.
Shell
```
ssh server.example.com
```
On a fleet, pre-populate the new key rather than having everyone accept it blind.
Shell
```
ssh-keyscan -t ed25519 server.example.com >> ~/.ssh/known_hosts
```

Confirm it workedThe connection succeeds and does not warn again on the next attempt.

If you need to undo itssh-keygen -R leaves a backup at ~/.ssh/known_hosts.old.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.