The “Host key verification failed” error after renaming a jump host

When you rename a jump host (or any SSH‑accessible machine) the client still keeps the old hostname in its ~/.ssh/known_hosts. On the next connection the client pulls the key presented by the renamed host and compares it with the stored key for the old name. The mismatch triggers the classic

Host key verification failed.

It’s a safety net against man‑in‑the‑middle attacks, but it can be a nuisance when you legitimately change the hostname. Below is a practical, step‑by‑step fix, a few automation tricks, and some security notes I’ve learned after 20 years on the grind.

1. What’s really happening

known_hosts is a plain text file. Each line looks like:

hostname,ip keytype key

When the host changes its DNS name, the hostname part changes, but the key stays the same. SSH sees a new hostname, looks for a matching entry, doesn’t find one, and falls back to the old entry. That old entry no longer matches the key the host is now presenting, so the client aborts.

2. Quick fix: drop the stale entry

The fastest way to get past the error is to delete the old line. You can hand‑edit it or let ssh-keygen do the heavy lifting.

Manual edit

# Open the file in your favourite editor
nano ~/.ssh/known_hosts

Search for the old hostname (or IP) and delete the line. Save and exit.

Using ssh-keygen

ssh-keygen -R old-jump-host.example.com

That removes every line that matches the hostname or IP. If you have several key types for the same host, you can be more specific:

ssh-keygen -R [old-jump-host.example.com]:22

3. Add the new key

With the old entry gone, reconnect:

ssh user@new-jump-host.example.com

SSH will ask you to accept the new key. Verify the fingerprint against a trusted source (the host’s console, a secure channel, or a quick ssh-keyscan) before accepting.

# Quick fingerprint check
ssh-keyscan -t rsa new-jump-host.example.com
# Compare the output with the host’s reported fingerprint

If you’re scripting and want a non‑interactive approach, pre‑populate the key:

ssh-keyscan -t rsa new-jump-host.example.com >> ~/.ssh/known_hosts

4. Automate for future renames

Renaming servers is common in cloud, containers, and CI/CD pipelines. Repeating the manual steps can become a pain point. Two patterns I’ve found useful:

4.1. Use a canonical hostname

Instead of tying the client to the actual host name, point everyone at a stable alias—e.g. jump.example.com. Update DNS or /etc/hosts whenever the underlying server moves. The known_hosts entry stays valid because the hostname never changes.

# /etc/hosts
192.0.2.10  jump.example.com

Clients connect via ssh user@jump.example.com. When the server is renamed or migrated, only the IP mapping changes.

4.2. Keep a central key store

For teams, put SSH host keys in a version‑controlled repo. When a server is renamed, update the key file and push the change. Clients can pull the latest known_hosts automatically:

git clone https://github.com/yourorg/ssh-keys.git
cp ssh-keys/known_hosts ~/.ssh/known_hosts

This gives you an audit trail of key changes and keeps everyone in sync.

5. Security considerations

5.1. Don’t abuse StrictHostKeyChecking=no

Temporarily disabling host‑key verification is tempting:

ssh -o StrictHostKeyChecking=no user@new-jump-host.example.com

But that opens the door to MITM attacks. Only use it in controlled scripts where you can guarantee the network path (e.g. a private VPN).

5.2. Verify fingerprints

Always compare the presented fingerprint with a trusted source. If you automate, pull the fingerprint from a secure endpoint—an HTTPS service that serves the host’s public key fingerprint is a good choice.

5.3. Keep keys fresh

If you rotate host keys (recommended every 3–5 years), remember to update known_hosts. Automating key rotation with ssh-keyscan and a central key store reduces the chance of stale entries.

6. Troubleshooting quick‑reference

7. Example workflow for a jump host rename

Assume you rename jump1.example.com to jump2.example.com.

# 1. Remove old entry
ssh-keygen -R jump1.example.com

# 2. Verify new key
ssh-keyscan -t ed25519 jump2.example.com >> /tmp/jump2.pub
# Compare fingerprint with the host’s console

# 3. Add new key
cat /tmp/jump2.pub >> ~/.ssh/known_hosts

# 4. Test connection
ssh user@jump2.example.com

If you’re using a central key store:

# Pull latest keys
git pull https://github.com/yourorg/ssh-keys.git
cp ssh-keys/known_hosts ~/.ssh/known_hosts

8. Updating ProxyJump after a rename

If you still need to hop through the renamed host, just update your ~/.ssh/config:

Host target
    HostName target.example.com
    ProxyJump user@jump2.example.com

The ProxyJump directive handles the intermediate hop. After the rename, only this line needs updating.

9. Weighing the options

Pick the method that fits your workflow and threat model. For most homelabs, a canonical hostname or a small Git repo of keys gives a good mix of safety and convenience.

10. Resources

• OpenSSH official repository – source of ssh-keyscan and ssh-keygen: https://github.com/openssh/openssh-portable
• Arch Linux SSH guide (good for key‑management practices): https://archlinux.org

Tags

ssh known-hosts security

See also

• How to Stop a systemd Timer from Failing After a Reboot Due to an Unset $USER Variable
• Converting a Nested JSON List of Users into a Simple CSV with jq and awk
• Fixing “Permission denied” on /tmp After a Kernel Update Removed the Sticky Bit
• Free Your Root Partition by Moving /var/log to a tmpfs: A Step‑by‑Step Guide
• Fixing a Failed /boot Mount in Emergency Mode on Ubuntu 24.04 LTS After a Kernel Update