The SSH client refused to connect because the server’s host key changed unexpectedly, which could indicate a man-in-the-middle attack or a legitimate server reinstallation.
Cause 1: Man-in-the-Middle Attack
Diagnosis: Check network traffic for unexpected SSH connections or unusual IP addresses attempting to proxy connections. Use tcpdump on the client to capture SSH traffic and analyze it for anomalies.
Fix: If a MITM attack is suspected, disconnect from the network immediately and investigate the source of the attack. Change all credentials and re-provision the server.
Why it works: This prevents further compromise by isolating the affected system and ensuring a clean slate.
Cause 2: Server Reinstallation or IP Address Change
Diagnosis: Verify the server’s identity through an out-of-band channel (e.g., a phone call to the administrator, checking a console). Confirm the new IP address if it has changed.
Fix: On the client machine, remove the old host key from ~/.ssh/known_hosts. The entry to remove will look like |1|... <server_ip_or_hostname> ssh-rsa .... Then, attempt to connect again. The client will prompt you to accept the new key.
Why it works: SSH clients store server host keys to detect tampering. When the server’s key changes (legitimately or not), the client flags it. Removing the old key and accepting the new one tells the client to trust the new key for this server.
Cause 3: Client-Side known_hosts File Corruption or Duplication
Diagnosis: Examine the ~/.ssh/known_hosts file on the client for duplicate entries for the same host or corrupted lines.
Fix: Manually edit ~/.ssh/known_hosts to remove duplicate or malformed entries. A simple way to do this is to comment out suspect lines with a # and try connecting. If that works, you can then permanently delete the commented lines.
Why it works: A corrupted or duplicated entry confuses the SSH client’s verification process, leading it to believe the host key has changed when it hasn’t, or it’s comparing against the wrong key.
Cause 4: DNS Spoofing
Diagnosis: Use dig or nslookup to query the DNS records for the server’s hostname and compare the IP address with the one you expect. Check /etc/resolv.conf to ensure you’re using a trusted DNS server.
Fix: Correct the DNS records to point to the correct IP address. If DNS spoofing is suspected on your network, investigate and secure your DNS infrastructure.
Why it works: If DNS is providing the wrong IP address for a hostname, the SSH client will try to connect to that wrong IP, which will have a different host key, triggering the verification failure.
Cause 5: SSH Server Configuration Change (sshd_config)
Diagnosis: On the server, check the sshd_config file (usually located at /etc/ssh/sshd_config) for any changes to HostKey directives.
Fix: If the HostKey directive was changed, ensure it points to the correct, newly generated host key file. Restart the SSH service: sudo systemctl restart sshd.
Why it works: The SSH server might have been configured to use a different host key file. Restarting the service ensures it loads the correct, active host key.
Cause 6: Time Synchronization Issues
Diagnosis: Check the system time on both the client and server using date. Significant time discrepancies can sometimes interfere with certificate-based authentication, which is related to host key verification.
Fix: Synchronize the time on both client and server using NTP. For example, on the client: sudo apt install ntp (or chrony) and sudo systemctl start ntp. On the server, ensure NTP is also running and configured correctly.
Why it works: While not directly causing host key verification failure, large time drifts can cause subtle issues in secure communication protocols, and ensuring accurate time is a good general practice for system stability.
The next error you’ll likely encounter if you’ve fixed the host key issue but haven’t addressed underlying network connectivity problems is "Connection refused" or a timeout.