This SSH warning appears when the host key for a remote server doesn't match the stored fingerprint in your known_hosts file, which can indicate DNS spoofing, server changes, or IP address reuse. Usually this is benign but requires verification.
When you connect to an SSH server, your client stores the server's host key fingerprint (ECDSA) in ~/.ssh/known_hosts. On subsequent connections, SSH verifies the current key matches the stored fingerprint. If the fingerprint doesn't match, SSH displays this warning because either: (1) you're connecting to a different server (legitimate), or (2) a man-in-the-middle attack is occurring (malicious). The warning is SSH's security mechanism to detect potential DNS spoofing or host key tampering.
First, confirm the SSH target is correct. Check your command:
ssh user@hostname
# or
ssh [email protected]If you're unsure about the target, contact your system administrator to confirm the expected IP address and that the server was recently replaced or updated.
SSH will show the server's new fingerprint in the warning message. Compare this fingerprint with the published SSH key fingerprints from your server provider or administrator. Log into your server provider's console or contact your admin to retrieve the current host key fingerprint and verify it matches what SSH is reporting.
Once you've verified the server is legitimate, remove the outdated entry using ssh-keygen (most efficient method):
# For hostname
ssh-keygen -f "~/.ssh/known_hosts" -R hostname.example.com
# For IP address
ssh-keygen -f "~/.ssh/known_hosts" -R 192.168.1.100This safely removes only the specific host entry without affecting other keys.
After removing the old entry, reconnect to the server:
ssh user@hostnameSSH will display the new host key fingerprint and ask if you trust it. Review the fingerprint against your documented value, then type yes to accept and store the new key in ~/.ssh/known_hosts.
Once you've accepted the new key, subsequent connections should work without warnings:
ssh user@hostnameYou should now connect without seeing the DNS spoofing warning.
If you need to prevent this warning in legitimate scenarios where servers are frequently replaced (e.g., auto-scaling cloud environments), consider using DNSSEC with SSHFP DNS records. Servers can publish their SSH keys via SSHFP records, and SSH clients configured to use DNSSEC will validate keys against DNS instead of known_hosts, avoiding key mismatch warnings on server reinstalls. Generate SSHFP records on the server with: ssh-keygen -r $(hostname --fqdn). Another option is to use StrictHostKeyChecking=accept-new in ssh_config for automation, but only in trusted internal networks. Always keep CheckHostIP enabled (default) to detect actual DNS spoofing attacks.
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
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH