How to fix The ECDSA host key for hostname has changed in SSH

SSHBEGINNERHIGHUpdated Jan 4, 2026· 243 views

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.

Quick fix

Fixes The ECDSA host key for hostname has changed

ssh-keygen -R hostname.example.com
  1. Verify the server is legitimate
  2. Remove the old host key using ssh-keygen
  3. Reconnect and accept the new host key
  4. Verify the connection works
ssh — error
ssh-keygen -R hostname.example.com
The ECDSA host key for hostname has changed

What this error means

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.

Typical symptoms

  • SSH connection fails with 'Remote Host Identification Has Changed' warning
  • Error message points to a line number in ~/.ssh/known_hosts where the old key is stored
  • Connection to the same hostname or IP worked previously
  • Manual SSH attempt is blocked before any password prompt
  • Error message suggests 'Offending ECDSA key in ~/.ssh/known_hosts' or similar
  • CI/CD pipeline fails when attempting to connect to a server

Common causes

  1. Server was reinstalled or its operating system was upgraded, regenerating new SSH host keys
  2. Server was deleted and recreated in a cloud provider using the same hostname or IP address
  3. SSH host keys were rotated or regenerated as part of server maintenance
  4. The server's IP address is shared with a different host that has different keys
  5. A hostname resolves to a different IP address than before (DNS change or migration)
  6. Network spoofing or man-in-the-middle attack attempting to intercept SSH connection

How to fix "The ECDSA host key for hostname has changed"

1Verify the server is legitimate

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.

2Remove the old host key using ssh-keygen

Once you've verified the server is legitimate, remove the outdated key from your known_hosts file using the ssh-keygen command:

bash
ssh-keygen -R hostname.example.com

Or if connecting by IP address:

bash
ssh-keygen -R 192.168.1.10

This command removes all entries for that hostname or IP from ~/.ssh/known_hosts. The -R flag tells ssh-keygen to remove the offending key.

3Reconnect and accept the new host key

After removing the old key, attempt to reconnect:

bash
ssh user@hostname.example.com

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.

bash
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])? yes
4Verify the connection works

Once you've accepted the new key, verify that SSH connections work normally:

bash
ssh user@hostname.example.com
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.

5Handle multiple entries for the same host

Some systems store host keys for both hostname and IP address. If you still get errors after removing by hostname, also remove by IP:

bash
ssh-keygen -R hostname.example.com
ssh-keygen -R 192.168.1.10

You can also manually edit ~/.ssh/known_hosts and remove lines containing the hostname or IP:

bash
nano ~/.ssh/known_hosts
# Find and delete the line(s) for your host

After manual editing, verify the file has valid syntax (each line should be one host entry).

Advanced notes

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:

bash
Host critical-server.example.com
  StrictHostKeyChecking accept-new
  User ubuntu

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

Frequently asked questions

What does "The ECDSA host key for hostname has changed" mean?
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. " 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.
How do I fix "The ECDSA host key for hostname has changed"?
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.
What causes "The ECDSA host key for hostname has changed"?
Server was reinstalled or its operating system was upgraded, regenerating new SSH host keys Server was deleted and recreated in a cloud provider using the same hostname or IP address SSH host keys were rotated or regenerated as part of server maintenance
Is the "The ECDSA host key for hostname has changed" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading