“Warning: Remote Host Identification Has Changed” — Did GitHub change their RSA key?

“Warning: Remote Host Identification Has Changed” — Did GitHub change their RSA key?

291

Just sometime ago I started getting this warning when pushing to GitHub.

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.

Is this normal and how do I resolve it?

Share
Improve this question

1

  • ssh-keygen -R github.com – this command does not update the previous ssh keys (your ~/.ssh/id_rsa & ~/.ssh/id_rsa.pub will remain unchanged).

    – Constantin De La Roche

    4 hours ago

5 Answers
5

Reset to default

Highest score (default)

Trending (recent votes count more)

Date modified (newest first)

Date created (oldest first)

368

This happened because on the 24th of March 2023, GitHub updated their RSA SSH host key used to secure Git operations for GitHub.com because the private key was briefly exposed in a public GitHub repository. You will get that message if you had remembered GitHub’s previous key fingerprint in your SSH client before that date.

As per per the linked blog post, the solution is to remove the old key by running this command:

$ ssh-keygen -R github.com

Now the next git connection (pull, push or clone) should ask if you trust the new SSH key. Before entering yes, ensure the shown new key is valid, using the list:

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

Refer to the blog post for other ways to fix the issue.

Share
Improve this answer

7

  • 18

    In addition, the fingerprints of GitHubs SSH keys can be found here: docs.github.com/en/authentication/…

    – Sever van Snugg

    Mar 24 at 8:28

  • 2

    Using Git Bash on Windows, I found that the above command worked, but on git push I got a message that the "authenticity of github.com can't be establish". Asked if I wanted to continue, I typed "yes" and now everything works again.

    – AlainD

    2 days ago

  • 7

    @AlainD: that's exepcted, because this command basically just says "forget the old public key" and the new one will be trusted the next time. If you want to be correct about it, it's better to save the new, known correct one ahead of time (the blog post tells you how).

    – Joachim Sauer

    2 days ago

  • 2

    I had an old RSA key for ssh.github.com in addition to the github.com ones hiding in ~/.ssh/known_hosts. Remove that if you see it; it will be updated after you type "yes" as described by @AlainD.

    – Jacob Crofts

    2 days ago

  • The $ ssh-keygen -R github.com command works for me, then accept the connection request to use git push command. Thanks!

    – Guru Bhandari

    yesterday

24

From Github:

At approximately 05:00 UTC on March 24 [2023], out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com. We did this to protect our users from any chance of an adversary impersonating GitHub or eavesdropping on their Git operations over SSH. This key does not grant access to GitHub’s infrastructure or customer data. This change only impacts Git operations over SSH using RSA. Web traffic to GitHub.com and HTTPS Git operations are not affected.

SOLUTION: Remove old RSA SSH key of github from .ssh/ known_hosts and update the new one.
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/#what-you-can-do

Share
Improve this answer

0

22

According to Github’s blog post, their SSH key was leaked and therefore they regenerated their key.

You need to remove your stored key by running:

$ ssh-keygen -R github.com

Which should output something like:

# Host github.com found: line 1
.ssh/known_hosts updated.

Followed by a command to fetch their new key:

$ curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts

Once completed, you can rerun the git command you were attempting.

Share
Improve this answer

3

  • NOT WORKING…. GIVING ERROR. $ curl -L api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts bash: jq: command not found % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 –:–:– 0:00:07 –:–:– 0 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: curl.haxx.se/docs/sslcerts.html

    – Kamlesh

    yesterday

  • curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

    – Kamlesh

    yesterday

  • @Kamlesh possibly jq library is missing on your side, try running this to install it: brew install jq. You'll need to have a brew installed as well (brew.sh).

    – nikitahl

    2 hours ago

15

Yes, GitHub updated their RSA host key as mentioned in their blog post. You can follow the directions there to update your keys.

However, some people find that OpenSSH has also saved the host key for IP addresses. This tends to be unhelpful, but it can be worked around like so (on Linux and Git Bash):

$ sed -i -e '/AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==/d' ~/.ssh/known_hosts

and like so on macOS:

$ sed -i '' -e '/AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==/d' ~/.ssh/known_hosts

That removes the key wherever it’s found, either for hostnames or IP addresses. Since GitHub uses multiple IP addresses, it’s not really possible to enumerate all of them and remove them all with ssh-keygen, so removing the key itself manually is the best option.

You can then follow the directions from the blog post to update the keys automatically:

$ curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | 
  sed -e 's/^/github.com /' >> ~/.ssh/known_hosts

Share
Improve this answer

3

On Ubuntu 20.04, using an ed25519 key on Github, even after running ssh-keygen -R github.com, per the main answer, I kept seeing these notifications each time I ran git push:

$ git push
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Offending key for IP in /home/gabriel/.ssh/known_hosts:14
Matching host key in /home/gabriel/.ssh/known_hosts:15
Are you sure you want to continue connecting (yes/no)? yes
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Offending key for IP in /home/gabriel/.ssh/known_hosts:14
Matching host key in /home/gabriel/.ssh/known_hosts:15
Are you sure you want to continue connecting (yes/no)? yes
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Offending key for IP in /home/gabriel/.ssh/known_hosts:14
Matching host key in /home/gabriel/.ssh/known_hosts:15
Are you sure you want to continue connecting (yes/no)? yes

So, I finally just removed my ~/.ssh/known_hosts file by renaming it like this:

(Update: try @bk2204’s answer instead of running the mv cmd below. Thanks, @Guntram Blohm).

mv ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

…and now git push finally works just fine again! I don’t care that I have to re-authenticate all my ssh destinations whenever I use ssh again to a particular server, so effectively removing the ~/.ssh/known_hosts file is fine. I hardly use ssh except for pushing to GitHub and GitLab anyway.

Note: the first time I ran git push after that I had to type yes, as shown below:

$ git push
The authenticity of host 'github.com (140.82.112.4)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,140.82.112.4' (ECDSA) to the list of known hosts.
Everything up-to-date

Before typing yes, however, I first verified on GitHub’s website that the SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM fingerprint was correct, and from GitHub. GitHub has the fingerprints for each key type here: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

These are GitHub’s public key fingerprints:

  • SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s (RSA)
  • SHA256:br9IjFspm1vxR3iA35FWE+4VTyz1hYVLIE2t1/CeyWQ (DSA – deprecated)
  • SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
  • SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)
Share
Improve this answer

11

  • 3

    This might be a workaround if you're not using ssh for anything else, but if you have other servers you connect to, this means any changes to their keys will go unnoticed. (And obviously you have some others as the keys are on lines 14 and 15 of your known_hosts. Better delete the key like in @bk2204's answer, or note the line number (14 in your case) and delete line 14 manually.

    – Guntram Blohm

    2 days ago

  • 6

    HTTPS and SSH use different private keys. The HTTPS private key was not leaked, just the SSH private key.

    – JBYoshi

    2 days ago

  • 1

    @JBYoshi, I see several upvotes on your comment, so can you explain more about what that means and how it is pertinent? I don't understand what you're telling me or if you're indicating I should do something differently, but want to learn more.

    – Gabriel Staples

    yesterday

  • 2

    Gabriel, JBYoshi is replying to Davislor who implied there was a circularity in checking the fingerprints with the key that you're trying to check. In reality, you're verifying SSH keys with fingerprints that are verified through HTTPS, that had not been affected by the leak. So no circularity. All good.

    – Luca Citi

    yesterday

  • 1

    Yep, they answered my question. There have been breaches where someone “verified” with a key or checksum that they got from a site the attacker controls.

    – Davislor

    20 hours ago

Not the answer you're looking for? Browse other questions tagged

or ask your own question.

Leave a Reply

Your email address will not be published. Required fields are marked *