SSH "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!": check it, then fix known_hosts
Fix the SSH host key warning safely: find out why the key changed, verify the new fingerprint on the server, then remove the old key with ssh-keygen -R.
by OhSudo ··
Not sure this is your cause?Find it step by step: Can't connect over SSH →
You connect to a server you’ve used many times, and SSH stops with a wall of @ signs:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!Someone could be eavesdropping on you right now (man-in-the-middle attack)!It is also possible that a host key has just been changed.The fingerprint for the ED25519 key sent by the remote host isSHA256:mQ7mVv3nF0aJ3c8Qe1v2p6m6rGv0nq0dJ0yQ2b9yH4E.Please contact your system administrator.Add correct host key in /home/guest/.ssh/known_hosts to get rid of this message.Offending ED25519 key in /home/guest/.ssh/known_hosts:7Host key for 203.0.113.10 has changed and you have requested strict checking.Host key verification failed.Every SSH server has a host key — its identity. The first time you connect, your client saves it in ~/.ssh/known_hosts. From then on it checks that the server still has the same key. Now the server answered with a different key, and SSH refuses, because that’s exactly what an attacker in the middle would look like.
Usually there’s an ordinary reason. But the right fix is: find the reason first, then remove the old key — not the other way round.
- The servershows its host keycompared with
- known_hostshas the key from last timethey don't match(fails)
- Different keySSH stops, to be safe(breaks here)
TL;DR
# 1. On the server (console, or another trusted way in): its real fingerprintssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub# 2. If it matches the one in the warning: remove the old key, connect againssh-keygen -R 203.0.113.10ssh guest@203.0.113.101. Is there an innocent explanation?
The key changes legitimately when:
- the server was reinstalled or rebuilt from an image (new host keys are generated on first boot);
- the address now belongs to another machine — common in the cloud, where a released IP is given to someone else’s new server, or your DNS name points to a replacement;
- several machines share one name or IP — a load balancer, a failover pair, a floating IP;
- someone regenerated the host keys on purpose.
If none of these happened, treat it as a possible attack: don’t type passwords or forward your agent until you’ve checked.
2. Verify the new key out of band
Compare the fingerprint in the warning with the one the server really has — through a channel an attacker can’t fake:
- on the server’s console (cloud provider’s web console, IPMI, a colleague who’s logged in):
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub256 SHA256:mQ7mVv3nF0aJ3c8Qe1v2p6m6rGv0nq0dJ0yQ2b9yH4E root@web01 (ED25519)- or from the cloud console output, where many images print their host key fingerprints at first boot.
Same fingerprint → the change is genuine. Different → stop and investigate.
3. Remove the old key and connect again
ssh-keygen -R 203.0.113.10It removes every entry for that host from known_hosts (and keeps a backup as known_hosts.old). If you also connect by name, remove that too: ssh-keygen -R web01.example.com. Then connect — SSH asks you to accept the new key once:
The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.ED25519 key fingerprint is SHA256:mQ7mVv3nF0aJ3c8Qe1v2p6m6rGv0nq0dJ0yQ2b9yH4E.Are you sure you want to continue connecting (yes/no/[fingerprint])?Compare it with what you verified, then answer yes.
ssh-keygen -R is better than editing the file by hand: on many systems known_hosts stores names hashed, so you can’t even find the line by reading it. The warning tells you the line number anyway (known_hosts:7).
Warning
Don’t make the warning go away for good with StrictHostKeyChecking no or UserKnownHostsFile /dev/null in your SSH config. That turns off the one check that protects you from connecting to the wrong machine. For short-lived lab VMs that get new keys all the time, limit it to a Host pattern that covers only them.
Automation: Ansible, CI, Git
Tools that connect without a person — Ansible, CI jobs, git over SSH — fail with Host key verification failed. and no way to answer. Add the verified key ahead of time:
ssh-keyscan -H 203.0.113.10 >> ~/.ssh/known_hostsssh-keyscan doesn’t verify anything — it trusts whatever answers. Run it once, check its fingerprint against the server, and store the result (in CI: as a secret or a file in the repository). GitHub, GitLab and Bitbucket publish their host key fingerprints in their documentation. See also Ansible UNREACHABLE.
Shell, we have a problem!
Similar, but different: Permission denied (publickey) — the host is fine, your key isn’t accepted; see SSH Permission denied (publickey). WARNING: POSSIBLE DNS SPOOFING DETECTED! — the key matches a known host, but under another name or IP; usually a reused IP or a renamed server — same checks.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.