Fix REMOTE HOST IDENTIFICATION HAS CHANGED SSH Warning Safely

You connect to a server you have used many times, and SSH stops dead with a wall of capital letters: REMOTE HOST IDENTIFICATION HAS CHANGED. The message warns that someone could be eavesdropping, mentions fingerprints, and refuses to let you in. It looks alarming, and that is deliberate. The warning is one of the most important safety features in SSH.

Most of the time, though, the cause is innocent. You rebuilt the server, reinstalled Ubuntu, replaced a Raspberry Pi, or your router gave the same IP address to a different machine. This guide shows you how to tell a harmless change from a real attack, and how to clear the warning safely, step by step, only when you have verified the new fingerprint.

Quick Answer

This warning means the SSH key presented by the server does not match the key your computer stored for that address in its known_hosts file. If you know the server was rebuilt, reinstalled, or replaced, verify the new fingerprint through a trusted route such as the server console, then remove the old entry with ssh-keygen -R server-address and reconnect, accepting the new key only when its fingerprint matches the one you verified. If you cannot explain the change, do not connect and investigate first.

What the Warning Actually Means

The first time you connect to an SSH server, your client records that server’s public host key in a local file, usually ~/.ssh/known_hosts. On every later visit, the client compares the key the server presents with the stored one. A match gives you a quiet login. A mismatch triggers the warning and blocks the connection, because from the client’s point of view there are only two possibilities: the server legitimately has a new key, or a different machine is pretending to be your server.

That second possibility is a man-in-the-middle attack. Treat the warning with respect, but do not panic: legitimate changes are far more common at home than attacks.

Common Legitimate Reasons the Key Changed

• You reinstalled the operating system. A fresh Ubuntu install generates brand new host keys during setup, so every client sees a change.
• You rebuilt or replaced the device. A new Raspberry Pi, a swapped server, or a recreated virtual machine all present different keys, even with the same name and address.
• An IP address moved to another machine. If your router reassigned 192.168.1.50 from an old laptop to a new NAS, your client compares the NAS key against the laptop entry and complains, correctly.
• You regenerated host keys manually. Commands such as sudo ssh-keygen -A after deleting keys, or restoring a disk image to new hardware, both change the fingerprint.
• DNS or hostname changes. Connecting by a new name can store a second entry, and confusion between the name and IP entries can surface as a mismatch.

Step 1: Stop and Identify What Changed

Before removing anything, spend one minute answering a simple question: did I, or someone I trust, change this server recently?

1. Read the warning carefully. It names the file and line number of the conflicting entry, and it shows the fingerprint of the key the server just presented.
2. Recall recent events: an OS reinstall, a new device, a router reset, a DHCP change, or a restored backup all explain the warning.
3. If nothing you know of has changed, treat the warning as suspicious. Do not proceed to clear it, especially on a work, school, or public network where interception is more plausible.
4. Note the exact address you used, whether a hostname or an IP, because the fix must target the same entry the warning names.

Step 2: Verify the New Fingerprint Through a Trusted Route

Safe clearing depends on confirming the new key from somewhere other than the connection that just warned you. Any of these routes works.

1. Console or direct access: sit at the server with a keyboard and monitor, or use your hosting provider’s web console, and log in locally.
2. On the server, display the fingerprint of its current host key with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub.
3. Compare that fingerprint, character for character, with the one shown in the warning on your computer. They must match exactly.
4. If the server is a fresh install you just performed yourself, that fact plus a matching console fingerprint is solid confirmation.
5. If the fingerprints do not match even at the console, something is genuinely wrong. Stop, disconnect, and investigate the network path before using SSH to that address again.

The official OpenSSH ssh-keygen manual page documents the fingerprint display and the removal options used in this guide, and the OpenSSH client manual page explains how known_hosts checking behaves.

Step 3: Remove the Old Entry the Clean Way

Once verification passes, remove only the stale entry. Avoid editing the whole file by hand unless you enjoy hunting through long hashed lines.

1. Run ssh-keygen -R 192.168.1.50, using the exact hostname or IP address from the warning. This deletes the matching old key and keeps a backup copy in known_hosts.old.
2. If you connect by both name and IP, repeat the command for the hostname too, for example ssh-keygen -R homeserver.
3. For servers reached on a custom port, the stored entry includes the port. Remove it with the bracket form, such as ssh-keygen -R "[192.168.1.50]:2222".
4. Reconnect with ssh yourname@192.168.1.50. SSH will show the new key fingerprint and ask whether to continue.
5. Compare the fingerprint in that prompt with the verified one from the console one more time. Only then type yes.

Step 4: If You Must Edit known_hosts by Hand

Sometimes the warning gives a line number and a manual edit is quicker, for example on a managed work machine without permission to run removal tools.

1. Make a backup first: cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak.
2. Open the file with nano ~/.ssh/known_hosts and delete exactly the line number named in the warning, no others.
3. Save the file and reconnect. Verify the fingerprint prompt against your trusted value before accepting, exactly as in the previous step.

If host entries appear as unreadable hashes rather than plain addresses, your client has hashed known hosts enabled. In that case the ssh-keygen -R method still works by matching the hash, while manual line hunting becomes guesswork, so prefer the tool.

Related Situations You May Meet Next

A similar but softer message says the key was added or that an additional key was found for the address. That usually follows connecting by a new name or address for a known server, and the same verification habit applies. Our guide on how to use SSH to connect to a remote server for the first time explains first-connection prompts and the known_hosts system in more beginner-friendly detail.

Also note that user login keys are separate from host keys. A full OS reinstall removes both, so you may need to reinstall your public key as well as accept the new host key.

Common Mistakes and Useful Tips

• Deleting the entire known_hosts file. That clears the warning but also throws away your verified record of every other server. Remove only the one stale entry.
• Typing yes without comparing fingerprints. The comparison is the security. Skipping it turns a strong protection into a pointless extra click.
• Disabling host key checking permanently. Options like StrictHostKeyChecking no silence warnings by abandoning verification altogether. Never leave them in a configuration file for convenience.
• Removing the entry for the wrong address. Name and IP entries are separate. If the warning persists, you removed one while connecting through the other.
• Ignoring an unexplained change. If nobody rebuilt anything and the fingerprint cannot be verified, believe the warning. Investigate the network or contact the server administrator.
• Tip: after a planned server rebuild, note the new fingerprint from the console before you sit down at your desk. Verification then takes seconds instead of a return trip.

Conclusion

The REMOTE HOST IDENTIFICATION HAS CHANGED warning is SSH doing its job: refusing to trust a server whose identity no longer matches your records. Handle it safely by pausing, explaining the change, and verifying the new fingerprint through a trusted route like the server console. Then remove the single stale entry with ssh-keygen -R, reconnect, and accept the new key only when the fingerprints agree. That routine keeps the protection strong while making legitimate rebuilds and replacements painless.

Frequently Asked Questions

Is this warning always a sign of an attack?

No. At home it is almost always a legitimate change such as a reinstall, a new device, or an IP address moving to different hardware. It becomes suspicious only when nothing has changed and the new fingerprint cannot be verified through a trusted route.

What does ssh-keygen -R actually do?

It finds and removes the stored host key for the address you name from your known_hosts file, keeping a backup in known_hosts.old. Your next connection then behaves like a first connection and asks you to confirm the new key.

Can I just delete the whole known_hosts file?

You can, but you should not. You would lose the verified keys for every server you use, and each one becomes an unverified first connection again. Removing the single stale entry is safer and just as fast.

Why does the warning return after I removed the entry once?

Usually because you connect through two addresses, such as a hostname and an IP, and only removed one entry, or because the address now belongs to a different device than the one whose key you accepted. Remove both entries and verify the fingerprint of the device you actually reach.

Should I set StrictHostKeyChecking to no to stop these warnings?

No. That disables the identity check that protects you from man-in-the-middle attacks. The correct response to the warning is verification and a targeted entry removal, not turning the protection off.