How to fix @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 347 views

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.

Quick fix

Fixes @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

ssh-keygen -R hostname_or_ip
  1. Verify the remote server identity through a secure channel
  2. Remove the old host key from known_hosts
  3. Reconnect to accept the new host key
  4. For scripted/CI environments: use -o StrictHostKeyChecking=no (with caution)
ssh — error
ssh-keygen -R hostname_or_ip
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

What this error means

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.

Typical symptoms

  • SSH connection is blocked with the warning box at the top
  • You cannot connect to the remote server until the issue is resolved
  • The warning mentions a specific line number in ~/.ssh/known_hosts
  • The offending key is listed as ECDSA, RSA, or ED25519 depending on the host key type

Common causes

  1. The remote server was rebuilt, reinstalled the OS, or regenerated its SSH host keys
  2. You're connecting to a cloud instance where an elastic IP was reassigned to a new server
  3. The server's SSH service was reconfigured or migrated
  4. DNS or hostname resolution changed, pointing to a different physical server
  5. A legitimate MITM attack or network spoofing is occurring (rare but possible)

How to fix "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"

1Verify the remote server identity through a secure channel

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.

2Remove the old host key from known_hosts

Use ssh-keygen to remove only the offending key entry:

bash
ssh-keygen -R hostname_or_ip

Replace hostname_or_ip with your actual hostname or IP address. For example:

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

This removes just that host's entry from ~/.ssh/known_hosts without deleting other trusted keys.

3Reconnect to accept the new host key

Now reconnect to the server:

bash
ssh user@hostname

SSH will prompt you to accept the new host key:

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

4For scripted/CI environments: use -o StrictHostKeyChecking=no (with caution)

If you're automating SSH in CI/CD or scripts and trust the server, you can skip the verification check:

bash
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@hostname

Warning: This disables a critical security check. Only use this in controlled, trusted environments. Never use it for production servers without understanding the risks.

Advanced notes

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:

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

Frequently asked questions

What does "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNI" mean?
SSH uses host keys (digital fingerprints) to verify that you're connecting to the server you expect. ssh/known_hosts. On subsequent connections, SSH compares the server's current key against the stored one.
How do I fix "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNI"?
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.
What causes "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNI"?
The remote server was rebuilt, reinstalled the OS, or regenerated its SSH host keys You're connecting to a cloud instance where an elastic IP was reassigned to a new server The server's SSH service was reconfigured or migrated
Is the "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNI" 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