Skip to main content
“REMOTE HOST IDENTIFICATION HAS CHANGED” means the server’s SSH host key differs from the one your computer saved on an earlier visit. After you rebuild or reinstall a server this is expected, because the new system has new keys. Confirm the new fingerprint on the server’s console, then remove the old entry with ssh-keygen -R 203.0.113.10 and connect again.

​
Before you start

  • A host key identifies the server, like an ID card. Your computer stores it in ~/.ssh/known_hosts on the first connection and checks it every time after.
  • The warning protects you from connecting to an impostor. Don’t remove the old key until you know why it changed.
  • This is a message on your computer. The commands run there, not on the server.

​
Why did the host key change?

From most to least likely:
  1. You rebuilt or reinstalled the server. A fresh system creates new host keys. See rebuild and reinstall your VPS.
  2. The IP now belongs to a different server, for example after you cancelled one server and ordered another, or a domain now points to a new machine.
  3. Someone regenerated the server’s host keys, for example with ssh-keygen -A after deleting them.
  4. Someone is intercepting the connection. Rare, but this is what the warning exists for. If none of the reasons above apply, check before you go on.

​
Step 1: Check the real fingerprint on the server

Open the VNC console (on a dedicated server, use KVM/IPMI access via a ticket), log in and run:
The warning on your computer shows the fingerprint the server sent (The fingerprint for the ED25519 key sent by the remote host is SHA256:...). If both match, the change is genuine. If the warning names an ECDSA or RSA key, check ssh_host_ecdsa_key.pub or ssh_host_rsa_key.pub instead.

​
Step 2: Remove the old key from your computer

If you connect on a custom port, the entry includes it:
If you also connect by name, remove that entry too: ssh-keygen -R example.com.

​
Step 3: Connect and accept the new key

Compare the fingerprint with Step 1 and type yes. You can also paste the fingerprint from Step 1 instead of yes; SSH then checks the match for you.

​
How to check it worked

Connect again. You should get straight to the login without any warning.

​
Frequently asked questions

​
Can I turn the check off with StrictHostKeyChecking no?

Don’t. It accepts any key, including an attacker’s. If you often rebuild test servers, use StrictHostKeyChecking accept-new in your SSH config: it saves keys for new hosts automatically but still blocks changed ones.

​
Can I keep the same host keys after a rebuild?

Yes, if you back up /etc/ssh/ssh_host_* before the rebuild and restore them afterwards (then restart SSH). Keep the private key files at permissions 600.

​
Is “Host key verification failed” alone the same problem?

Usually. Without the big warning, it can also mean you answered no to the first-connection question, or ran SSH in a script with no terminal to ask. Connect once interactively and accept the key.

VPS and dedicated server guides

Every guide in this section.

Connect with SSH

First connection and fingerprints.

SSH config shortcuts

Per-host settings, including accept-new.

Permission denied (publickey)

The next error after a rebuild.

Use PuTTY

Connect from Windows with PuTTY.
Checked against the official OpenSSH ssh, ssh_config and ssh-keygen manuals on 4 November 2026; the warning, ssh-keygen -R (including a custom port), the first-connection prompt and fingerprint checks were reproduced with a test SSH server on Ubuntu 24.04 LTS (OpenSSH 9.6). The Windows and PuTTY steps were not tested.

​
Need Extra Help?

If you encounter any issues, our support team is ready to assist:

​
Save on Your Hosting

Ready to upgrade your hosting? Use code KB20 at checkout for 20% off your first order!
Last Updated: November 2026