This warning appears when SSH detects that a remote server's host key has changed. It prevents connections as a security measure to detect potential man-in-the-middle attacks or legitimate server reinstallations. The fix involves removing the old key from your local known_hosts file.
When you connect to an SSH server, your local SSH client stores the server's public host key in the ~/.ssh/known_hosts file for future reference. If the server's key changes (because it was reinstalled, the host key was regenerated, or you're connecting to a different server on the same IP), SSH will refuse to connect and warn you that the "REMOTE HOST IDENTIFICATION HAS CHANGED". This is a security feature designed to protect you from man-in-the-middle attacks. The "Offending ECDSA key" message specifically identifies that the host key mismatch involves an ECDSA (Elliptic Curve Digital Signature Algorithm) key, and tells you the exact line number in your known_hosts file where the outdated key is stored.
The safest and most direct method is to use ssh-keygen with the -R flag, which removes all keys belonging to a specific hostname or IP address:
ssh-keygen -R hostname_or_ipReplace hostname_or_ip with the actual hostname or IP shown in the error. For example:
ssh-keygen -R 192.168.1.100Or with a hostname:
ssh-keygen -R example.comThis will output something like:
# Host 192.168.1.100 found: line 3
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.oldThe command creates a backup (.old file) before removing the key, so you can restore it if needed. This is the cleanest approach because it removes all entries for that host, preventing duplicate warnings.
If you want to manually remove only the specific line mentioned in the error:
1. Open the known_hosts file in your editor:
nano ~/.ssh/known_hosts2. Find and delete the line number shown in the error message (e.g., if the error says "line 47", delete line 47)
3. Save and exit (Ctrl+X, then Y, then Enter in nano)
Then try connecting again:
ssh user@hostnameSSH will prompt you to verify the new host key fingerprint. If you trust the server, type yes to add the new key to known_hosts.
If you're comfortable with command-line tools, you can use sed to remove a specific line by number. Replace 47 with the actual line number from your error:
sed -i '47d' ~/.ssh/known_hostsThe -i flag tells sed to edit the file in place. This is useful for scripting or one-liners.
Warning: Make sure you get the line number correct. If unsure, use the manual edit method or ssh-keygen instead.
After removing the offending key, attempt to reconnect to the server:
ssh user@hostnameSSH will show you the server's new host key fingerprint and ask if you trust it:
The authenticity of host 'example.com (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?Type yes to add the new key to your known_hosts file. If you can verify the fingerprint against a trusted source (e.g., your server admin), that's even better—it ensures you're not being man-in-the-middle attacked.
After this, the connection should proceed normally and future connections to this host will not warn you.
If you still get the warning after removing the key:
1. Check if you have both hostname AND IP address entries in known_hosts that conflict:
grep -n 'example.com|192.168.1.100' ~/.ssh/known_hostsIf both appear, remove both and reconnect. SSH may store entries for both the hostname and its IP separately, and they can have different keys if the server was rebuilt.
2. Verify the server's fingerprint matches what you expect:
ssh-keyscan -t ecdsa example.com | ssh-keygen -l -f -This shows the current key fingerprint on the server without connecting.
3. If you suspect a legitimate change (e.g., you just rebuilt the server), verify by contacting your server admin or checking your infrastructure management console to confirm the host keys were intentionally regenerated.
Security Note: The "Remote Host Identification Has Changed" warning is a genuine security feature designed to protect you from man-in-the-middle attacks. Always verify that the host key change is legitimate before proceeding. If you didn't rebuild or reconfigure the server, and you weren't expecting a key change, investigate further—it could indicate an actual security issue on your network.
Hashed Entries: Modern SSH stores known_hosts with hashed hostnames for privacy. If your known_hosts file contains hashed entries (lines starting with "|1|"), ssh-keygen -R still works—it will find and remove the matching hash.
Docker and CI/CD Pipelines: In containerized environments or CI/CD pipelines, this error is common when containers are rebuilt frequently. A common pattern is to add StrictHostKeyChecking=no to skip this check (less secure) or to manage a shared known_hosts file that includes pre-trusted keys.
Debugging: To see which keys are causing the issue, use:
ssh-keyscan -t ecdsa,rsa,ed25519 hostname 2>/dev/null | ssh-keygen -l -f -This shows the current server keys without connecting, helping you verify if a key change is expected.
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
bind: Address already in use
How to fix "bind: Address already in use" in SSH