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

SSH remembers the server’s host key from last time. If the key suddenly differs, OpenSSH stops and prints a scary warning — that is deliberate, not a bug.

Read the warning

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Host key verification failed.

SSH is telling you the cryptographic identity of the machine at that name/IP is not the one it stored before. The connection is refused on purpose so a silent swap cannot go unnoticed.

What known_hosts is for

On first successful connect, OpenSSH saves the server’s host key fingerprint in ~/.ssh/known_hosts (sometimes also /etc/ssh/ssh_known_hosts). Every later connect must present the same key. That stops a man-in-the-middle from pretending to be your server after you have already trusted it once.

When a change is expected

• You rebuilt or resized a VPS and the provider minted a new host key.
• You switched to a new cloud image or restored from a snapshot that had different keys.
• The server’s admin ran ssh-keygen -A / regenerated /etc/ssh/ssh_host_*.
• GitHub / GitLab / similar published a planned host-key rotation (rare; they announce fingerprints on their status/docs sites — compare before accepting).
• Multipass, WSL, local VMs often get a new key every time you delete and recreate the instance on the same name or IP.

If you did none of those things, treat the warning as serious: confirm the fingerprint out-of-band (provider panel, another admin, a previous screenshot) before trusting the new key.

Remove ONE host line — not the whole file

# Default SSH port 22:
ssh-keygen -R example.com
ssh-keygen -R 203.0.113.10

# Non-default port — brackets are required:
ssh-keygen -R '[example.com]:2222'
ssh-keygen -R '[203.0.113.10]:2222'

ssh-keygen -R deletes every line for that host (all key types) and usually writes a backup as known_hosts.old. Then connect again and accept the new fingerprint only after it matches the provider console.

• Do not rm ~/.ssh/known_hosts. That throws away trust for every other host you use and trains you to ignore the warning.
• Do not set StrictHostKeyChecking no or UserKnownHostsFile=/dev/null in a permanent config. Those options exist for throwaway automation against disposable lab VMs; they disable the protection this warning is for.

Check the fingerprint

# What your machine currently trusts:
ssh-keygen -F example.com -l

# What the server offers now (from a machine that can reach it, or the provider’s “reset host key” panel):
ssh-keyscan -t ed25519,rsa example.com 2>/dev/null | ssh-keygen -lf -

Compare the SHA256 fingerprint with the one shown in your cloud console. Matching hashes mean the new key is the real server; you can proceed after ssh-keygen -R. Paste two fingerprints into the hash generator if you want a quick side-by-side check of the text.

Multipass, WSL and reused names

Local hypervisors often reuse localhost, a fixed IP, or a stable hostname for brand-new VMs. Each recreate looks like a host-key change. Prefer ssh-keygen -R for that name/IP after a recreate, or give each VM a unique HostName in ~/.ssh/config so known_hosts entries do not collide.

Related

ssh Connection refused port 22 · Permission denied (publickey) · SSH key permissions are too open · ssh Connection timed out port 22 · fatal: Authentication failed for (HTTPS)

Questions

Published 5 November 2026.