Handling SSH Host Key Changes the Right Way

That scary SSH warning about a changed host identification is usually harmless when you've intentionally replaced hardware, reinstalled an OS, or reprovisioned a machine. Here's how to cleanly remove the old host key and trust the new one.

🔍What's Actually Happening

When you SSH to a remote host for the first time, your client stores that machine's unique host key in ~/.ssh/known_hosts. This fingerprint helps protect against man-in-the-middle attacks.

If you later connect to the same IP address or hostname but the host key has changed, SSH raises an alarm because it could mean:

Legitimate change: You reinstalled the OS, swapped hardware, or reprovisioned the system
Security threat: Someone is intercepting your connection (rare in trusted networks)

ℹ️

If you intentionally changed the machine, the fix is simple: remove the old key and accept the new one.

✅The Clean & Safe Fix

The recommended approach uses ssh-keygen to surgically remove only the offending entry from your known_hosts file.

1
Remove the old host key by IP address
SSH tells you exactly where the problem is. Use that line number or target the IP directly:
bash
```
ssh-keygen -R 192.168.9.72
```
This removes only the entry for 192.168.9.72, leaving the rest of your known_hosts intact.
2
If you also connect by hostname, remove that too
bash
```
ssh-keygen -R atlas-pi
```
This ensures the hostname entry is also cleaned up.

Reconnect and accept the new key

Now SSH again:

bash

ssh [email protected]

You'll see the fingerprint prompt:

text

The authenticity of host '192.168.9.72' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?

Type yes to store the new key.

✅

Result: New host key stored, device trusted, warning gone forever (unless it changes again).

🔧Alternative Approaches

While ssh-keygen -R is cleanest, here are other methods:

Option 2: Manually Edit known_hosts

SSH tells you exactly which line is the problem. You can open the file and delete that specific line:

bash

# Open in your preferred editor
nano ~/.ssh/known_hosts
# or
code ~/.ssh/known_hosts

# Delete the offending line (e.g., line 13), save, and exit

⚠️

This works but is error-prone—easy to delete the wrong line or corrupt the file format.

Option 3: Nuclear Option (Not Recommended)

Delete the entire known_hosts file:

bash

rm ~/.ssh/known_hosts

🚨

This forces SSH to re-trust every host you connect to. Only use this if you have very few known hosts or don't care about the security benefit of host verification.

🚀Best Practices for Long-Lived Infrastructure

If you frequently reprovision nodes in a homelab or cluster:

✅ Prefer Hostnames Over IPs

If your DNS is reliable, connect by hostname:

bash

ssh atlas-pi.internal.example.net

This avoids IP collision issues when IPs get reused across different machines.

✅ Expect Host Key Changes

When you reinstall an OS, swap hardware, or replace nodes, this SSH warning is a feature, not a bug. It's working as designed.

✅ Optional: Preload Host Keys (Advanced)

For automation (Ansible, provisioning scripts), you can pre-fetch and store host keys:

bash

ssh-keyscan atlas-pi >> ~/.ssh/known_hosts

Useful for non-interactive SSH scenarios where you can't manually accept keys.

📋Quick Reference

Remove old key and reconnect:

bash

# Remove by IP
ssh-keygen -R 192.168.9.72

# Remove by hostname (if applicable)
ssh-keygen -R atlas-pi

# Reconnect
ssh [email protected]

# Type "yes" when prompted

✅

In Summary: Use ssh-keygen -R <IP> to remove the old key, then ssh again and type yes to trust the new one. Clean, surgical, safe.

Filed under: SSH, Security, Linux, CLI, known_hosts, Infrastructure