SSH shows this warning when the remote host's key fingerprint has changed or doesn't match your stored record. This is a critical security alert that requires verification before proceeding, as it could indicate a man-in-the-middle attack or a legitimate server change.
When you connect to an SSH server, your client stores the server's unique cryptographic host key (fingerprint) locally in the known_hosts file. This fingerprint acts as a digital signature to verify you're connecting to the same trusted server every time. When SSH detects that the server's presented key doesn't match the stored fingerprint, it halts the connection and displays this warning. This mechanism exists to protect you from man-in-the-middle (MITM) attacks, where an attacker positioned between you and the legitimate server could intercept your connection, present their own fake SSH key, and capture your credentials or sensitive data. The warning means SSH detected an unexpected change and is refusing to proceed automatically.
Before removing any keys, determine whether the host key change is expected. Check your hosting provider's dashboard, contact your server administrator, or review recent maintenance notifications. Do NOT proceed if you cannot verify the legitimacy of this change, as doing so could expose you to a man-in-the-middle attack.
On your server's hosting console, look for information about server reinstalls, OS updates, or key rotations that would explain the key change.
If you have access to the server through another method (console, admin panel, phone call to administrator), verify the new host key fingerprint matches what you're about to accept.
On the target server, run:
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pubOr for RSA keys:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pubCompare the fingerprint output with what your SSH client is showing. They must match exactly.
Once you've verified the server change is legitimate, remove the outdated host key entry:
ssh-keygen -R hostname_or_ip_addressReplace hostname_or_ip_address with your actual server's hostname or IP. For example:
ssh-keygen -R example.com
ssh-keygen -R 192.168.1.100If you're using both hostname and IP, run the command twice:
ssh-keygen -R example.com
ssh-keygen -R 192.168.1.100This command removes only the entries matching that host, leaving other known_hosts entries intact.
Now attempt to reconnect to the server:
ssh user@hostname_or_ipSSH will prompt you to confirm the new host key fingerprint:
The authenticity of host 'example.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:xxxxx...
Are you sure you want to continue connecting (yes/no/[fingerprint])?Type yes to accept the new key and store it in known_hosts. You should now be connected successfully.
For cloud environments: Cloud providers frequently reuse IP addresses. If you're connecting to a previously used IP that's now assigned to a different server, you'll encounter this warning. Always verify you're connecting to the correct instance.
StrictHostKeyChecking: Never permanently disable host key checking in production environments. Options like StrictHostKeyChecking=no bypass SSH's core security feature and should only be used in controlled, trusted scenarios. Disabling this is like removing half of SSH's protections.
Manual known_hosts editing: As an alternative to ssh-keygen, you can manually edit ~/.ssh/known_hosts with a text editor and delete the line containing the old key. However, ssh-keygen -R is safer as it removes only the specific host entry.
Multiple entries: If you have both hostname and IP address entries for the same server in known_hosts, you must remove both to avoid future warnings.
SSH key types: Different SSH implementations use different key types (ED25519, RSA, ECDSA). When the server regenerates keys, it may use a different type, which also triggers this warning.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH