SSH Remote Host Identification Has Changed Warning

The warning is the full-page block of capital letters that says "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY". It is the protection SSH offers against a man-in-the-middle, and most of the time the real cause is dull. A decision is needed each time: is this change expected? The mechanism is explained in host key verification failed, and the steps assume OpenSSH 9.x.

What the message says

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The fingerprint for the ED25519 key sent by the remote host is
SHA256:Zk3...example.
Offending ED25519 key in /home/alice/.ssh/known_hosts:14
Host key verification failed.

The output gives the line number of the stale entry (14 here). The file ~/.ssh/known_hosts stores one key per host, and the client compared the key the server sent with it. The connection is refused before any credentials are sent, so nothing leaks.

Decide whether the change is expected

Expected:     you rebuilt the VM, reinstalled the OS, replaced the server, reassigned the IP,
              or the host was re-keyed in a security rotation.
Unexpected:   nothing changed on the server, you are on a new network (hotel, cafe), the
              warning appears for a host you use daily.

Ask the person or system that runs the server. Cloud instances recreated with the same address are the most common cause. An unexpected change on a stable host, particularly on an untrusted network, deserves caution: do not proceed until you have verified.

Verify the new key

# on the server (console access or a trusted channel)
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# on your machine, what the server presents now
ssh-keyscan -t ed25519 server.example.test 2>/dev/null | ssh-keygen -lf -

256 SHA256:Zk3abcExampleFingerprintOnlyForThisPost root@server (ED25519)
256 SHA256:Zk3abcExampleFingerprintOnlyForThisPost server.example.test (ED25519)

If the fingerprints match, the server is the one you expect, and the stored key was out of date. Cloud providers often show the fingerprint in the console or in the boot log. Publishing host fingerprints in DNS (SSHFP records) or distributing a shared known_hosts through configuration management removes the manual step.

Remove the old entry

ssh-keygen -R server.example.test
ssh-keygen -R 203.0.113.10
ssh [email protected]

# Host server.example.test found: line 14
/home/alice/.ssh/known_hosts updated.
Original contents retained as /home/alice/.ssh/known_hosts.old
The authenticity of host 'server.example.test (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:Zk3abcExampleFingerprintOnlyForThisPost.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Remove both the host name and the IP, since entries are stored for each. Compare the fingerprint shown with the verified one before typing yes. With HashKnownHosts yes, host names in the file are hashed, so searching by text fails; ssh-keygen -R handles the hashes correctly, so use it instead of editing the file.

What not to do

Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

That configuration silences the warning for every host forever and gives up the protection. It is a common copy-paste from forums. If automation needs to connect to freshly created machines, pin the key ahead of time with ssh-keyscan from a trusted channel, or use StrictHostKeyChecking accept-new, which accepts a first-time key but still blocks a changed one. See the SSH config guide.

Why the warning exists

The first time you connect to a host, SSH records its public key in known_hosts. On later connections it compares the key the server presents against the stored one. A mismatch could mean the server was reinstalled or its key rotated, or it could mean someone is intercepting the connection. SSH cannot tell the difference, so it stops and prints a large warning. That refusal is the protection working. The risk of the usual advice, which is to delete the line and carry on, is that it treats an attack and a reinstall the same. The only safe way to continue is to learn which of the two happened by checking through a channel you trust.

The message names the offending line and file, such as line 12 of ~/.ssh/known_hosts, and the fingerprint of the new key. Both are useful. The line number shows which entry would be removed, and the fingerprint is what you compare with the server's real one.

Common benign causes

Most changes are harmless. A server rebuilt from an image generates new host keys on first boot. A cloud instance replaced at the same IP address gets a different key, which is common when addresses are reused. A load balancer that sends you to different back ends, each with its own key, makes the warning appear at random. A host whose name now points to a different machine after a DNS change produces the same effect. And a change of SSH server software can alter the key types offered, so the client sees a different algorithm than the stored one.

If the same hostname legitimately resolves to a pool of servers, give them all the same host key through configuration management, or use SSH certificates signed by a certificate authority, so clients trust the authority and ignore individual keys.

Checking the key through another path

To verify, get the fingerprint from somewhere other than the connection that is being questioned. Options include the cloud provider's console output for the instance, which prints the host key fingerprints at first boot, a colleague with console access who runs ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub on the server, or a fingerprint published in the team's documentation. Compare the result with the fingerprint in the warning. If they match, the change is expected. If they do not, stop and treat it as a possible interception: do not enter a password or send a key to that host, and raise it with whoever manages the network.

Prefer publishing host keys in DNS as SSHFP records with DNSSEC, or distributing a signed known_hosts file, in environments where hosts change often. That moves the check from each user's judgement to a controlled process.

Removing the old entry cleanly

Use ssh-keygen -R hostname to delete the stale entry instead of editing the file by hand. It removes all lines for that name and keeps a backup as known_hosts.old. If the file hashes host names, the command still finds the right line. Remember to remove the entry for the IP address as well when it was recorded separately, and then connect again and confirm the new fingerprint when prompted. Avoid disabling checking with StrictHostKeyChecking no or pointing UserKnownHostsFile at /dev/null, except for throwaway test machines. Those options turn off the protection for every connection that uses them, and they have a way of surviving in configuration long after the day they were added.

For automated systems the question is different, because no person is present to judge a fingerprint. A deployment host that rebuilds servers should have its host keys managed: bake them into the image, fetch them from a secrets store at boot, or sign them with a certificate authority. Then the clients' records stay valid across rebuilds, and the warning keeps its meaning for the rare case when something is truly wrong. Treating the warning as noise in automation trains everyone to ignore it, and the day it matters nobody looks.

Record the date and reason whenever you change a host key, in the same place you track other infrastructure changes, so the next surprise can be matched to a cause quickly.

Where this does not apply

Servers behind load balancers with different host keys on each node trigger the warning at random: give all nodes the same keys or use SSH certificates, as in SSH certificates. Round-robin DNS has the same effect. See the ssh-keygen manual and the StrictHostKeyChecking description.