The remote server's SSH host key no longer matches what's stored in your known_hosts file. This warning protects against man-in-the-middle attacks but usually indicates a legitimate server change. You can safely resolve it by removing the old key.
SSH uses host keys (digital fingerprints) to verify that you're connecting to the server you expect. When you connect to a host for the first time, your SSH client saves its public key to ~/.ssh/known_hosts. On subsequent connections, SSH compares the server's current key against the stored one. If they don't match, SSH blocks the connection and displays this warning. This is a critical security feature that alerts you to potential attacks where someone might be intercepting your connection. However, this warning also appears when legitimate server changes occur—like OS reinstallation, SSH key regeneration, or IP address reuse after server replacement.
Before accepting the new key, contact the server owner or administrator through a separate, trusted channel (phone, email, Slack, etc.) to confirm that the server has changed.
This is crucial for security. Never blindly accept a new host key without verification.
Use ssh-keygen to remove only the offending key entry:
ssh-keygen -R hostname_or_ipReplace hostname_or_ip with your actual hostname or IP address. For example:
ssh-keygen -R example.com
ssh-keygen -R 192.168.1.100This removes just that host's entry from ~/.ssh/known_hosts without deleting other trusted keys.
Now reconnect to the server:
ssh user@hostnameSSH will prompt you to accept the new host key:
The authenticity of host 'hostname (IP)' can't be established.
ECDSA key fingerprint is SHA256:xxxxx...
Are you sure you want to continue connecting (yes/no)?Type yes to accept the new key. It will be saved to ~/.ssh/known_hosts for future connections.
If you're automating SSH in CI/CD or scripts and trust the server, you can skip the verification check:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@hostnameWarning: This disables a critical security check. Only use this in controlled, trusted environments. Never use it for production servers without understanding the risks.
Security Considerations
This warning is SSH's way of preventing man-in-the-middle (MITM) attacks. Always verify the server identity before accepting a new key, especially for production systems.
PuTTY Users (Windows)
PuTTY stores keys in the Windows registry instead of a text file:HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
Find the entry matching your hostname and delete it using the Registry Editor. You'll be prompted to accept the new key on your next connection.
CloudFormation / Terraform / Infrastructure as Code
When you redeploy infrastructure, servers often get new host keys. You may need to rebuild your host key cache as part of your CI/CD process:
# Clear entire known_hosts for fresh start
rm -f ~/.ssh/known_hosts
# Or use StrictHostKeyChecking=no for automated deployments
export SSH_OPTS="-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"Distinguishing Legitimate Changes from Attacks
- Legitimate: You just rebuilt the server, or the system administrator told you to expect a key change
- Suspicious: You didn't rebuild anything, no one informed you of changes, and this is a production system
When in doubt, escalate to your team's security or infrastructure lead before accepting the new key.
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