How to fix Warning: the ECDSA host key for 'hostname' differs from the key for the IP address in SSH

SSHBEGINNERMEDIUMUpdated Jan 4, 2026· 233 views

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.

Quick fix

Fixes Warning: the ECDSA host key for 'hostname' differs from the key for the IP address

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:65
  1. Check SSH command for exact error location
  2. Remove the IP address entry using ssh-keygen
  3. If needed, remove the hostname entry too
  4. Reconnect to accept the new key
ssh — error
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:65
Warning: the ECDSA host key for 'hostname' differs from the key for the IP address

What this error means

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.

Typical symptoms

  • Warning message appears: "the ECDSA host key for 'hostname' differs from the key for the IP address"
  • SSH connects successfully despite the warning
  • Multiple lines in known_hosts for the same host with different keys
  • Warning appears inconsistently depending on whether you use hostname or IP
  • CI/CD pipelines fail due to StrictHostKeyChecking settings despite warning
  • Manual SSH connection shows 'Offending key' location in known_hosts file

Common causes

  1. Server SSH keys were regenerated (e.g., after OS reinstall, security incident, or key rotation)
  2. Connecting to same host via both hostname and IP address creates separate known_hosts entries
  3. Time-skewed systems where keys were stored at different times and have drifted
  4. Hostname DNS resolution changed, pointing to a different server with different keys
  5. Load balancer or reverse proxy rotated backend servers without updating SSH host keys
  6. Certificate/key migration: server moved from one host identity to another
  7. Man-in-the-middle attack (rare, but possible if fingerprints don't match official sources)

How to fix "Warning: the ECDSA host key for 'hostname' differs from the key for the IP address"

1Check SSH command for exact error location

When you see the warning, SSH shows you which line in known_hosts contains the offending key:

bash
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:65

Note the line numbers. This tells you where both keys are stored. You need to remove one or both.

2Remove the IP address entry using ssh-keygen

The safest method is to remove only the IP address entry, keeping the hostname entry:

bash
ssh-keygen -R 192.168.1.100

Or if GitHub/a remote service warned you, use their IP:

bash
ssh-keygen -R 140.82.113.3

This removes ALL keys associated with that IP address from known_hosts. SSH will ask you to confirm:

bash
/home/user/.ssh/known_hosts updated.
Original contents have been backed up to /home/user/.ssh/known_hosts.old

A backup is automatically created in case you need to restore it.

3If needed, remove the hostname entry too

If you want to clean both entries and re-accept the keys:

bash
ssh-keygen -R example.com
ssh-keygen -R 192.168.1.100

Both entries are now removed from known_hosts.

4Reconnect to accept the new key

After removing the entries, connect again. SSH will prompt you to accept the host key:

bash
ssh user@example.com
# or
ssh user@192.168.1.100

You'll see:

bash
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.

5Verify the server's fingerprint (optional but recommended)

If this is a critical server (GitHub, production database, etc.), verify the fingerprint before accepting:

bash
ssh-keyscan -t ecdsa example.com

Compare 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.

6Disable IP address checking in SSH config (optional)

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:

bash
Host example.com
    CheckHostIP no
    User myusername

The 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 notes

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:

bash
Host example.com 192.168.1.100 web.example.local
    CanonicalizeHostname yes
    CanonicalDomains example.com
    User myuser

Security 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.

Frequently asked questions

What does "Warning: the ECDSA host key for 'hostname' differs from the key for th" mean?
ssh/known_hosts) to verify that hosts you connect to haven't changed. 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.
How do I fix "Warning: the ECDSA host key for 'hostname' differs from the key for th"?
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.
What causes "Warning: the ECDSA host key for 'hostname' differs from the key for th"?
Server SSH keys were regenerated (e.g., after OS reinstall, security incident, or key rotation) Connecting to same host via both hostname and IP address creates separate known_hosts entries Time-skewed systems where keys were stored at different times and have drifted
Is the "Warning: the ECDSA host key for 'hostname' differs from the key for th" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading