This warning occurs when SSH stores different ECDSA keys for the same host accessed via both its hostname and IP address. It typically appears after a server reinstall, key regeneration, or when connecting via multiple identifiers. The warning is usually harmless but indicates SSH can't verify the connection is to the expected host.
SSH maintains a `known_hosts` file (`~/.ssh/known_hosts`) to verify that hosts you connect to haven't changed. When you connect to the same server using both a hostname (like `example.com`) and its IP address (like `192.168.1.100`), SSH stores separate entries for each. If the ECDSA keys in those entries don't match—either because the server's keys changed or SSH stored them at different times—SSH warns you that the host identification has changed. This can happen when servers are rebuilt, SSH keys are regenerated for security, or when connecting to a server before and after a certificate renewal.
When you see the warning, SSH shows you which line in known_hosts contains the offending key:
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.113.3'
Offending key for IP in /home/user/.ssh/known_hosts:18
Matching host key in /home/user/.ssh/known_hosts:65Note the line numbers. This tells you where both keys are stored. You need to remove one or both.
The safest method is to remove only the IP address entry, keeping the hostname entry:
ssh-keygen -R 192.168.1.100Or if GitHub/a remote service warned you, use their IP:
ssh-keygen -R 140.82.113.3This removes ALL keys associated with that IP address from known_hosts. SSH will ask you to confirm:
/home/user/.ssh/known_hosts updated.
Original contents have been backed up to /home/user/.ssh/known_hosts.oldA backup is automatically created in case you need to restore it.
If you want to clean both entries and re-accept the keys:
ssh-keygen -R example.com
ssh-keygen -R 192.168.1.100Both entries are now removed from known_hosts.
After removing the entries, connect again. SSH will prompt you to accept the host key:
ssh [email protected]
# or
ssh [email protected]You'll see:
The authenticity of host 'example.com (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?Type yes to add it back to known_hosts.
If this is a critical server (GitHub, production database, etc.), verify the fingerprint before accepting:
ssh-keyscan -t ecdsa example.comCompare the fingerprint shown against the official documentation:
- GitHub's keys: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints
- Your server admin should provide the correct fingerprint
If the fingerprint doesn't match, DO NOT accept the key—contact your server administrator.
If you frequently access the same server via both hostname and IP, you can configure SSH to skip IP verification:
Create or edit ~/.ssh/config:
Host example.com
CheckHostIP no
User myusernameThe CheckHostIP no directive tells SSH to only verify the hostname, not the IP. This prevents the warning if you later connect via IP to the same host.
Note: Only use this for hosts you trust. Disabling IP checking slightly reduces security verification.
Advanced troubleshooting:
HashKnownHosts Configuration: If your SSH config has HashKnownHosts yes, hostnames are hashed in known_hosts for privacy. This makes it harder to see which entries correspond to which hosts. You can list unhashed hosts with grep -v '^#' ~/.ssh/known_hosts | cut -d ' ' -f1 (note: some entries will still be hashed). Set HashKnownHosts no in ~/.ssh/config if you need to manage entries manually.
CanonicalizeHostname: Use CanonicalizeHostname yes in ~/.ssh/config to map multiple hostnames to a single canonical form. This prevents duplicate known_hosts entries:
Host example.com 192.168.1.100 web.example.local
CanonicalizeHostname yes
CanonicalDomains example.com
User myuserSecurity Consideration - Man-in-the-Middle: While usually harmless, this warning CAN indicate a man-in-the-middle attack. If the ECDSA fingerprint doesn't match any official documentation, the server might have been compromised or you're being intercepted. Always verify critical server fingerprints with your infrastructure team.
Load Balancers and Auto-Scaling: If connecting to servers behind a load balancer that rotates backends, different IPs may have different keys. Configure your client to verify by hostname only, or ensure all backend servers share the same SSH keys.
Git-specific note: If you see this warning for GitHub or GitLab, it's almost always safe to remove the IP entry. These services use the same keys for all IP addresses they advertise. However, always verify the fingerprint against official documentation first.
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