Fixing the Git “REMOTE HOST IDENTIFICATION HAS CHANGED” Warning
The Git REMOTE HOST IDENTIFICATION HAS CHANGED warning is an SSH security alert that fires when the host key fingerprint of a remote server no longer matches the one cached in your ~/.ssh/known_hosts file. It is most often a legitimate server-side key rotation, not an attack.
I was pushing a quick fix to one of my blog posts when I hit a glitch. While pushing my changes to this blog repository, I received the response:
git push origin master
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Did you see this message too? How do you fix it? And what are SSH and RSA keys, and their fingerprints?
I will cover these things in this concise post. I hope it will be helpful for you, or I will reread it when I am 80 :)
Fix: “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”
Error: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! when running git push, git pull, or any ssh command against github.com.
Cause: The server’s SSH host key fingerprint differs from the cached entry in ~/.ssh/known_hosts — commonly a legitimate key rotation (GitHub rotated its RSA host key in March 2023), occasionally a man-in-the-middle attack.
Fix: Remove the stale key, then re-add GitHub’s current key after verifying the fingerprint:
# 1. Delete the old cached host key
ssh-keygen -R github.com
# 2. Fetch and append GitHub's current SSH host keys
curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts
The rest of this post explains the SSH and RSA concepts behind the warning.
chatGPT Explains the SSH Host Key Warning
I am becoming lazy. I have asked the chatGPT AI about that message.
Elena: I have got a Git issue. WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
chatGPT: If you receive a "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" error message when you try to connect to a Git repository, it means that the SSH key fingerprint for the remote host has changed since the last time you connected to it. This could be due to several reasons, such as the remote host being reconfigured or a man-in-the-middle attack.
Next, I follow and test what chatGPT suggested. We still need to investigate what is going on.
Verify the host key
You can verify the key fingerprint to ensure that it matches your expectations. To do this, run ssh-keygen -F {hostname} to see the fingerprints of the SSH keys already cached for that host.
ssh-keygen -F github.com
You must compare the output with the fingerprints listed on the GitHub page; see GitHub’s SSH key fingerprints. If the fingerprint does not match the one you expect, then you should not connect to the remote host.
GitHub suggests adding its published key entries to ~/.ssh/known_hosts directly, so you are not left manually confirming an unfamiliar fingerprint prompt the next time you connect.
🔒 Subscribe to keep reading.
Why the SSH Host Key Changed: GitHub’s 2023 RSA Key Rotation
🔒 Subscribe to keep reading.
First, we delete the old key
🔒 Subscribe to keep reading.
Download and add it
🔒 Subscribe to keep reading.
What Are SSH Keys?
🔒 Subscribe to keep reading.
What Is an SSH Host Key Fingerprint?
🔒 Subscribe to keep reading.
Creating and Using SSH Keys on macOS
🔒 Subscribe to keep reading.
Conclusion
🔒 Subscribe to keep reading.
References
🔒 Subscribe to keep reading.
You've hit a Deep Dive tutorial.
I spend dozens of hours researching, coding, and breaking things to write these guides. This content is free, but reserved for my subscriber community. Drop your email below to unlock this guide (and all past/future deep dives):
Full content temporarily unavailable — refresh in a moment
Already a subscriber? Use the magic link from your last newsletter, or reset your password.
Log in to unlock
New subscribers get an inbox mail: Set a password to unlock articles. The form does not log you in — use the same email afterwards.