Fixing SSH Error: Host key verification failed - Remote Host Identification Has Changed

TL;DR: The Quick Fix

If you trust the server and know why its identity changed—perhaps you just reinstalled Ubuntu or swapped a cloud instance—run this command on your local machine to wipe the stale entry:

ssh-keygen -R 192.168.1.105

Replace 192.168.1.105 with your server's IP or hostname. Next time you connect, SSH will ask you to accept the new fingerprint. Just type yes and you're back in.

Why SSH is Blocking You

Think of this error as a security guard blocking the door because your server's "ID card" doesn't match what's on file. When you first connect to a remote machine, SSH saves its unique public key in ~/.ssh/known_hosts. It acts as a digital fingerprint.

Every subsequent connection performs a handshake. If the fingerprint has changed, SSH panics. It assumes someone might be intercepting your traffic via a Man-in-the-Middle (MITM) attack. While the warning looks scary, it's usually triggered by routine administrative changes.

What usually triggers the warning?

• OS Reinstalls: You wiped the server and reinstalled a fresh copy of Debian or CentOS.
• IP Recycling: Your cloud provider assigned you an IP (like 10.0.0.42) that belonged to a different server last week.
• Hardware Swaps: You moved your project to a new physical machine but kept the same static IP.
• SSH Key Rotation: A sysadmin manually regenerated the server's host keys for security compliance.

How to Fix It

Method 1: Use ssh-keygen (The Pro Way)

This is the most reliable approach. It handles hashed hostnames and complex formatting within your known_hosts file automatically. It searches for the specific IP and scrubs all old entries related to it.

# Use the IP or domain name of your server
ssh-keygen -R 192.168.1.105

If you connect via a custom port, like 2222, you must include it exactly as formatted in the error log:

ssh-keygen -R [192.168.1.105]:2222

Method 2: Manual Surgery

Sometimes you only want to touch one specific line. Look at the error message on your screen; it usually points directly to the problem line. For example:

Offending ECDSA key in /home/user/.ssh/known_hosts:24

Line 24 is the culprit. Open the file using your favorite terminal editor:

nano ~/.ssh/known_hosts

Scroll down to line 24, delete it entirely, save, and exit. This is a quick fix if you have multiple entries for the same IP and only want to remove one.

Method 3: Temporary Bypass for Automation

In automated environments or CI/CD pipelines where you spin up dozens of temporary VMs, checking host keys can be a bottleneck. You can bypass the check entirely, though you should never do this on a public, untrusted network.

ssh -o "StrictHostKeyChecking=no" root@192.168.1.105

This command forces the connection to proceed regardless of the fingerprint. Use this sparingly.

Verifying the Change

Try connecting again after clearing the old key. You'll see a prompt like this:

The authenticity of host '192.168.1.105 (192.168.1.105)' can't be established.
ED25519 key fingerprint is SHA256:nU8zR9X... 
Are you sure you want to continue connecting (yes/no)?

Type yes. SSH will append the new, correct key to your local file, and the connection will proceed normally.

Pro-Tips for Network Management

Frequent identity changes often stem from messy IP management. If you are running a home lab or a local dev cluster, DHCP might be reassigning IPs every 24 hours, causing constant SSH headaches. I use ToolCraft's Subnet Calculator to map out static IP ranges for my VMs. By locking a server to a static address like 192.168.1.200, you drastically reduce the chance of IP collisions and stale known_hosts entries.

Keeping your CIDR blocks organized ensures that when a host key does change, you'll know it was intentional rather than a configuration error.

Further Reading

• Run man ssh-keygen to see advanced management options.
• Check man ssh_config to understand how UserKnownHostsFile works.
• Learn about SSHFP DNS records to automate host key verification securely.