This error occurs when the SSH client detects that a server's ECDSA host key has changed from what is stored locally. It's a security warning that prevents automatic connection to the server, requiring you to verify that the host hasn't been compromised or replaced.
SSH maintains a local database of known host keys (in ~/.ssh/known_hosts) to protect against man-in-the-middle attacks. When you connect to a server, SSH verifies that the server's host key matches what's stored locally. If the stored key differs from what the server presents, SSH refuses to proceed and warns you that "the host identification has changed." This is a critical security feature because a different host key could indicate that someone is spoofing the server or that the server has been compromised. However, it can also occur legitimately when a server is reinstalled, when its SSH keys are regenerated, or when the host was recreated.
Before removing the old key, verify that the server you're connecting to is actually the one you expect. Contact the server administrator out-of-band (through email, chat, or phone) to confirm:
- Whether the server was recently reinstalled or recreated
- Whether SSH keys were intentionally rotated
- The new host key fingerprint (if available) to compare against what SSH reports
This step is crucial because a host key change could legitimately indicate a security incident. Only proceed if you've confirmed the server change is authorized.
Once you've verified the server is legitimate, remove the outdated key from your known_hosts file using the ssh-keygen command:
ssh-keygen -R hostname.example.comOr if connecting by IP address:
ssh-keygen -R 192.168.1.10This command removes all entries for that hostname or IP from ~/.ssh/known_hosts. The -R flag tells ssh-keygen to remove the offending key.
After removing the old key, attempt to reconnect:
SSH will now show a new warning: "The authenticity of host can't be established. ECDSA key fingerprint is...". This is normal for the first connection after removing the old key.
Type yes to accept the new host key. SSH will then add the new key to ~/.ssh/known_hosts.
The authenticity of host 'hostname.example.com (192.168.1.10)' can't be established.
ECDSA key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yesOnce you've accepted the new key, verify that SSH connections work normally:
ssh [email protected]
echo "SSH connection successful"If the connection succeeds, you can now use SSH normally. Future connections to this host will use the new key without warnings.
Some systems store host keys for both hostname and IP address. If you still get errors after removing by hostname, also remove by IP:
ssh-keygen -R hostname.example.com
ssh-keygen -R 192.168.1.10You can also manually edit ~/.ssh/known_hosts and remove lines containing the hostname or IP:
nano ~/.ssh/known_hosts
# Find and delete the line(s) for your hostAfter manual editing, verify the file has valid syntax (each line should be one host entry).
Man-in-the-Middle Attack Risk: The primary purpose of this warning is to protect against MITM attacks where an attacker intercepts your SSH connection and presents their own key. If you're uncertain about whether the server change is legitimate, DO NOT proceed with removing the key. Instead, contact your system administrator through a trusted channel to verify the host key change.
Host Key Fingerprints: SSH can show you both the old and new key fingerprints for comparison. You can look up the server's official key fingerprint (if published by your hosting provider or organization) to verify it matches what SSH reports. GitHub and other major services publish their host key fingerprints publicly for verification.
Cloud Environments: In cloud providers like AWS, Azure, or GCP, when you terminate and recreate an instance with the same IP or hostname, the new instance will have different SSH host keys. Always verify through the cloud provider's console or by contacting your infrastructure team before removing old keys.
StrictHostKeyChecking: For critical production systems, you can use SSH configuration to enforce stricter key checking. Add to ~/.ssh/config:
Host critical-server.example.com
StrictHostKeyChecking accept-new
User ubuntuThis allows new hosts to be added automatically but prevents connections to hosts with changed keys, forcing you to explicitly verify changes.
Scripting and Automation: If you're automating SSH connections (in CI/CD or scripts), use the -o StrictHostKeyChecking=no flag with caution and only for non-critical connections. For production, always maintain a pre-populated known_hosts file or use key-based authentication with certificate pinning.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH