Victor's room

Overview & Root Cause Summary: The error WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! Host key verification failed is an OpenSSH security safeguard triggered when the cryptographic public host key presented by the remote server differs from the key previously recorded in your local ~/.ssh/known_hosts file. While designed to prevent Man-in-the-Middle (MitM) eavesdropping attacks, it most frequently occurs when a remote server, cloud instance (AWS EC2, DigitalOcean Droplet), or Docker/Vagrant VM is reinstalled, rebuilt, or reassigned an existing IP address.

Understanding the Root Causes

• Server Reinstallation or OS Rebuild: When a server is re-imaged or SSH daemon packages are reinstalled, new host keys (RSA, ECDSA, ED25519) are generated in /etc/ssh/, causing a mismatch with existing client records.
• Dynamic IP Reassignment: In cloud and local DHCP environments, a previously accessed IP address is reassigned to a different physical or virtual machine.
• Port Forwarding / Ephemeral Local VMs: Local containers, Vagrant boxes, or WSL instances sharing localhost:2222 rotate keys frequently, colliding with previously stored keys for [localhost]:2222.
• Potential Man-in-the-Middle (MitM) Attack: An unauthorized entity on the network is actively intercepting traffic or impersonating the remote server.

Step 1: Quick Fix (Remove the Outdated Key Using ssh-keygen -R)

The safest and cleanest method to clear the mismatched entry is using the built-in OpenSSH key management utility.

# 1. Remove the old host key using the IP address or hostname:
ssh-keygen -R 192.168.1.100

# For non-standard port connections (e.g., port 2222 on localhost):
ssh-keygen -R "[localhost]:2222"

# For domain names:
ssh-keygen -R example.com

# 2. Reconnect to the server. OpenSSH will prompt to accept the new fingerprint:
ssh user@192.168.1.100
# Type 'yes' to store the new authentic key in ~/.ssh/known_hosts.

Step 2: Manual Removal of Offending Line from known_hosts

If your known_hosts file contains hashed entries or you prefer direct line removal, target the exact line number indicated in the error message (e.g., Offending key in ~/.ssh/known_hosts:42).

# On Linux (GNU sed):
sed -i '42d' ~/.ssh/known_hosts

# On macOS (BSD sed requires an empty string argument):
sed -i '' '42d' ~/.ssh/known_hosts

# Alternatively, open and edit with nano:
nano ~/.ssh/known_hosts
# Navigate to line 42, delete the line (Ctrl+K), and save (Ctrl+O, Enter, Ctrl+X).

Step 3: Configuration for Ephemeral / Local Development VMs (~/.ssh/config)

For frequently destroyed and recreated test environments (e.g., local Vagrant, Docker, or staging clusters), disable host key verification exclusively for specific IP ranges.

# Edit your client SSH config:
nano ~/.ssh/config

# Add a scoped rule for local test instances (DO NOT apply to wildcards '*' or production):
Host 192.168.56.* 10.0.0.* localhost
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel ERROR

Verification & Testing Steps

Verify that the new host fingerprint matches the authentic key generated on the server before confirming the connection.

# 1. On the remote server, display the authentic ED25519 key fingerprint:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# 2. On your local client, run ssh-keyscan to inspect the incoming fingerprint:
ssh-keyscan -t ed25519 192.168.1.100 | ssh-keygen -lf -

# 3. Connect with verbose debugging if any handshake issues persist:
ssh -vvv user@192.168.1.100

Summary Comparison Table