How to Fix SSH Host Key Verification Failed and Disable Strict RSA Checking in Linux


3 views

When you see the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" message, SSH is doing its job of protecting you from potential Man-in-the-Middle (MITM) attacks. This occurs when:

  • The server's host key has genuinely changed (common after OS reinstallation)
  • The server's IP address was previously used by another machine
  • The server's SSH keys were regenerated
  • There's actually a security breach in progress

The most straightforward way to resolve this is to remove the old key from your known_hosts file:

ssh-keygen -R host1
# Or specifically for the line mentioned in your error:
sed -i '377d' ~/.ssh/known_hosts

Then try connecting again - you'll be prompted to accept the new key.

For temporary connections where security isn't critical (like testing environments), you can disable strict host key checking:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@host1

Warning: This completely disables host key verification and makes you vulnerable to MITM attacks.

To modify SSH client behavior persistently, edit your SSH config file:

nano ~/.ssh/config

Add these lines for a specific host:

Host host1
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Or globally (not recommended for production):

Host *
    StrictHostKeyChecking no

Your additional symptom of immediate disconnection suggests either:

  1. The server's SSH daemon is configured to reject clients with mismatched host keys
  2. Network-level interference (firewall rules, IDS systems)
  3. Server-side MaxAuthTries or MaxSessions limitations

Check server logs for clues:

journalctl -u sshd --no-pager -n 50
# Or on older systems:
tail -50 /var/log/auth.log

When you need to legitimately change host keys, follow this process:

# On the server:
sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server
# Or on RHEL/CentOS:
sudo ssh-keygen -A
sudo systemctl restart sshd

Then notify users to update their known_hosts:

ssh-keygen -R host1
ssh-keyscan host1 >> ~/.ssh/known_hosts

For more security than completely disabling checks, verify the new fingerprint manually:

ssh-keyscan -t rsa host1 | ssh-keygen -lf -

Compare this with the fingerprint provided by your server administrator, then add explicitly:

ssh-keyscan host1 >> ~/.ssh/known_hosts

When you encounter the "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" message, SSH is detecting a mismatch between the stored host key in your ~/.ssh/known_hosts file and the current server's key. This typically occurs when:

  • The server's SSH keys were regenerated (common after OS reinstallation)
  • The server's IP address was reassigned to a different machine
  • A legitimate key rotation was performed
  • A MITM (Man-in-the-Middle) attack is occurring (worst case scenario)

The most straightforward fix is to remove the old key from your known_hosts file. The error message conveniently tells you the exact line number (377 in this case):

sed -i '377d' ~/.ssh/known_hosts

Or alternatively:

ssh-keygen -R host1  # For a specific host
ssh-keygen -R 192.168.1.100  # If you know the IP

For emergency access or automated scripts, you can temporarily disable strict checking:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@host1

Warning: This should only be used in trusted environments as it defeats SSH's man-in-the-middle protection.

For development environments where host keys change frequently, add these to ~/.ssh/config:

Host host1
    HostName host1.example.com
    User root
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Before disabling verification, always:

  1. Verify the new fingerprint with your server administrator
  2. Check if the server's SSH keys were intentionally rotated
  3. Compare the fingerprint through an alternative secure channel

To manually verify a server's fingerprint:

ssh-keyscan host1 | ssh-keygen -lf -

The "Connection reset by peer" error suggests additional issues:

  • Check server's SSH configuration: grep -i "MaxAuthTries" /etc/ssh/sshd_config
  • Verify network connectivity: tcptraceroute host1 22
  • Inspect server logs: journalctl -u ssh --no-pager -n 50