SSH Host Authenticity Warning: How to Fix It

The “host authenticity can’t be established” warning appears when your SSH client connects to a server whose host key is not yet known or has changed. To fix it, you verify the server’s host key fingerprint with the system administrator and then accept it by typing yes at the prompt; if the key has changed, you must remove the old key from your known_hosts file first.

What Triggers the Warning

SSH uses host keys to prove the identity of the server you are connecting to, preventing man-in-the-middle attacks. The first time you connect to a new server, your client has no record of that server’s host key, so it shows the warning and asks you to confirm the fingerprint. This is normal and happens once per server per user account.

The warning also appears when the server’s host key has changed since your last connection. This can happen if the server was reinstalled, its SSH configuration was regenerated, or if you are actually connecting to a different machine (possibly a malicious one). The message will say “REMOTE HOST IDENTIFICATION HAS CHANGED” and will refuse to connect until you remove the old key from your known_hosts file.

How to Fix It: First-Time Connection

When you see the warning for a brand-new server, follow these steps:

1. Contact the server administrator or check the hosting provider’s documentation to obtain the correct host key fingerprint (e.g., SHA256:… or MD5:…).
2. Compare that fingerprint with the one shown in the warning message. They must match exactly.
3. If they match, type yes and press Enter. The key will be saved to your ~/.ssh/known_hosts file.
4. If they do not match, do not accept. Stop the connection and investigate—someone may be intercepting your traffic.

You can also verify the fingerprint manually using a tool like ssh-keygen on the server (if you have access) or by asking the administrator to run ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub.

How to Fix It: Changed Host Key

If the warning says the host key has changed, you need to remove the old key before you can reconnect. Use the following command, replacing server.example.com with the actual hostname or IP address:

ssh-keygen -R server.example.com

This removes the old key from your known_hosts file. After that, try connecting again. You will see the first-time warning, and you can verify the new fingerprint as described above before accepting it.

If you manage the server yourself and did not intentionally change the host key, investigate why it changed. Check for unauthorized access or a compromised server. If you are unsure, contact your system administrator or hosting provider.

How to Avoid the Warning in the Future

For frequently used servers, you can add their host keys to your known_hosts file manually, or use SSH certificates for automated authentication. However, the standard warning is a security feature and should not be disabled globally.

If you are automating connections (e.g., in scripts), you can use the StrictHostKeyChecking=no option, but this is risky because it disables host key verification entirely. A safer approach is to use the ssh-keyscan command to pre-populate the known_hosts file with the server’s keys, then verify them once.

ssh-keyscan -t rsa,ecdsa,ed25519 server.example.com >> ~/.ssh/known_hosts

After running this, review the added lines to ensure they match the official keys. This is useful for CI/CD pipelines and other automated environments.

Common Problems and Misconceptions

One common misconception is that the warning means your password is being sent insecurely. In fact, the warning appears before any authentication, and your password is never sent until the host key is accepted. The risk is that an attacker could impersonate the server and capture your password if you accept a wrong key.

Another issue is that some users type yes without verifying the fingerprint, which defeats the security purpose. Always verify the fingerprint out-of-band (e.g., via a phone call, a ticket system, or the provider’s website).

If you are behind a corporate firewall or using a VPN, the warning may appear because the connection is being routed through a proxy that terminates SSL/TLS. In that case, the proxy’s host key is what you see, and you should contact your IT department.

Comparing SSH Host Key Algorithms

SSH supports several host key algorithms, each with different security properties:

• RSA (2048/4096-bit) – Widely supported, but older and slower. Still considered secure if the key is long enough.
• ECDSA (256/384/521-bit) – Based on elliptic curves, faster and shorter keys. Supported by most modern clients.
• Ed25519 – A modern, fast, and secure elliptic curve algorithm. Recommended for new deployments.

When you see the fingerprint, it will be prefixed with the algorithm (e.g., SHA256:... for RSA). The default key type used by your client may differ from the server’s preferred type. You can specify the key type with ssh -o HostKeyAlgorithms=ssh-ed25519 if needed.

Security Implications and Best Practices

Host key verification is your first line of defense against man-in-the-middle attacks. Always treat the warning seriously. Here are some best practices:

• Keep a record of the fingerprints for your critical servers in a secure place (e.g., a password manager).
• Use SSH certificates for large fleets of machines to simplify key management.
• Regularly audit your known_hosts file and remove entries for decommissioned servers.
• Never set StrictHostKeyChecking=no as a permanent setting in your global SSH config.

If you are an administrator, you can publish your host key fingerprints on your website or in DNS (via SSHFP records) so users can verify them easily. This reduces the chance of users blindly accepting a wrong key.

Frequently Asked Questions

Why does the warning appear even though I connected before?

This happens when the server’s host key has changed. It could be due to a server reinstall, a changed SSH configuration, or a different server at the same IP. Remove the old key with ssh-keygen -R and then re-verify the new fingerprint.

Is it safe to type ‘yes’ without checking the fingerprint?

No. Typing yes without verifying the fingerprint exposes you to man-in-the-middle attacks. Always compare the fingerprint with a trusted source before accepting.

Can I disable the warning permanently?

Yes, by setting StrictHostKeyChecking no in your SSH config, but this is strongly discouraged because it removes host key verification entirely. Only do this in isolated, low-security environments.

What does ‘REMOTE HOST IDENTIFICATION HAS CHANGED’ mean exactly?

It means the host key presented by the server does not match the one stored in your known_hosts file. SSH automatically blocks the connection to prevent potential attacks. You must remove the old key and verify the new one.

How do I find the correct host key fingerprint for a server I manage?

Run ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub (replace rsa with the appropriate type) on the server. The output is the fingerprint you should share with users.

Can I use SSH keys instead of passwords to avoid this warning?

No, the host key warning is separate from user authentication. You will still see it the first time you connect, even if you use SSH keys. The warning is about the server’s identity, not your login method.

Related

• LG TV Connect to Wi-Fi: Setup and Troubleshooting
• RAM for Running AI Models Locally: How Much Do You Need?
• Automating Claude Tasks: What Happens to Your Data