Has GitHub changed his remote host key ?

[obrassard]

Select Topic Area

Question

Body

Hello, since a couple of minutes, git is throwing me a warning for all my git push / git pull operations.

obrassard@mbp:timesentry [main] ►  git pull
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.
The fingerprint for the RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Host key for github.com has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

Is this an intended change from GitHub or should I investigate my network security ?!

Thanks in advance !

[crisman]

I too saw the unexpected host key ~15 minutes before you (around 2023-03-24T02:57:30Z), it went away a few minutes later. I failed to get the IP address of the endpoint I was talking with.

[lomkju]

This was the IP being used.

❯ whois 20.27.177.113 | grep Organization
Organization:   Microsoft Corporation (MSFT)

[crisman]

Which does have the correct host key now.

[comex]

Same here, seen from three different hosts in different parts of the US. No longer occurring.

[jl-applied]

Saw this an hour ago and seeing it again now.

[CyberShadow]

https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

[emg110]

I am seeing this now too, connecting from digital ocean servers (ubnuntu)

[guenther-brunthaler]

The fingerprints on

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

are still the old ones!

[interglobalmedia]

Yes they are. People have to know to go to the post. And of course no one is "officially notified" about such changes. For me, it was that I could not connect with Github, and then I had to go through a myriad of searches until I used the "right" keywords that matched the answers I needed. And I learned about the post via another post on another site. This should not be like this. Other similar sites actually let you know about changes directly. This has to change.

Who knows what else is out there in the docs that is no longer correct?

[crisman]

Note the translation notice at the top of the page:

Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.

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

[Akash1134]

👋 Hello, I can confirm we have recently changed our public RSA SSH host key used for GitHub.com.

You may receive a warning message which is expected for users that had our previous key verified. Please refer to our post on the GitHub Blog for more information and remediation steps: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

[austinarchibald]

Fixed it for me, thanks.

[NicoleCarlucci]

Where can I find the known_hosts file? It seems I can't find it anywhere... Thanks

[airtower-luna]

It's in ~/.ssh/, where the ~ stands for your home directory (where that is depends on your system).

[Abhay22]

It worked thanks alot

[AaganMaskey]

I managed to resolve the issue. Thanks!

[denyeo]

After I followed the instructions to remove the old RSA key for 'github.com', git pull started using the ECDSA key* supplied by github.com, and now shows this warning:

Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '20.205.243.166'
Offending key for IP in /home/forge/.ssh/known_hosts:87
Matching host key in /home/forge/.ssh/known_hosts:88
Are you sure you want to continue connecting (yes/no)?

In this case, I think the old ECDSA RSA key for the github.com IP needs to be removed from known_hosts. This can be done with:
ssh-keygen -f ~/.ssh/known_hosts -R GITHUB_IP_HERE
It worked for me, hope this helps. (Fill in the github.com IP that you see in the warning.)

I'm not sure why the ECDSA key of the github.com IP has supposedly changed - maybe someone can clarify this?
It did not change - ssh was notifying that the ECDSA key supplied by 'github.com' was not the same as the old RSA key for github.com's IP recorded in my system. The warning is unclear, but there's no problem.

* Github seems to have given ECDSA (or ED25519) preference in the ssh key negotation, causing ECDSA/ED25519 to become the default key type when you connect via SSH after removing the old RSA key fingerprint.

[airtower-luna]

@maxi-alibrate, that disables an important security check, basically like ignoring certificate errors in the browser, which would allow anyone to fake a server.

The Jenkins user should have its own known_hosts file, which you'll need to update just like your own.

[maxi-sante]

@airtower-luna thank you, you are right, I have chosen it momentarily, because I've updated known_hosts like this the error is "Host key verification failed", do you have any idea why?

[ShubhamTelus]

@Akash1134 - can you please help here, our jenkins job are failing with verfication failed error

[hassan-munir-confiz]

We have fixed our jenkins through following steps:

• Remove RSA key from known_hosts file.
• Copy paste only RSA from the github given site ( github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk= ) in known_hosts file.
• Then on jenkins run any git command clone or pull, on terminal enter yes to the given prompt.
• It may show offending key for IP issue fix it by using above command.
• Repeated this process for jenkins and all our EC2 instance and jenkins is working as expected.

So key notes from above steps are :

Make sure to copy only RSA key
Say yes to prompt shown on terminal.

According to my understanding, our jenkins setup is old like 4-5 years due to which only RSA work for us iother two keys are causing issue. It is my hutch i am not confident about this.

Hope above steps fixed your jenkins issue.

[ShubhamTelus]

@hassan-munir-confiz - thankyou for response, will try this and update here if this works.

[gustaff-weldon]

@Akash1134 When are you guys going to fix the Github Actions runners? Our ubuntu builds are failing with the warning when cloning the repo:

git fetch --quiet --depth 1 origin a306cf6304420dfad2f6c82e3e9136e8ca162d20
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    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.

The fingerprint for the RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.

Please contact your system administrator.

Add correct host key in /root/.ssh/known_hosts to get rid of this message.

Offending RSA key in /root/.ssh/known_hosts:1

Host key for github.com has changed and you have requested strict checking.

Host key verification failed.

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
: exit status 128

[Akash1134]

Hi @gustaff-weldon

With GitHub Actions you may see failed workflow runs if you're are using actions/checkout with the ssh-key option. We are updating the actions/checkout action in all our supported tags, including @v2, @V3, and @main. If you pin the action to a commit SHA and use the ssh-key option, you’ll need to update your workflow. You can read more about this process in our official documentation for Actions security hardening.

For more information, please visit our official documentation on GitHub’s SSH public key fingerprints.

[gustaff-weldon]

With GitHub Actions you may see failed workflow runs if you're are using actions/checkout with the ssh-key option. We are updating the actions/checkout action in all our supported tags, including @v2, @V3, and @main.

@Akash1134 we are using v3 and without ssh option, the only option we use is fetch-depth and it is only in a few out of over 90 usages

[Akash1134]

@gustaff-weldon I'll have to get this checked with our Actions engineers. However, we have just resolved an Actions incident - Just to be sure, could you please clone the repo again to see if the runners still return the same exit status?

[Akash1134]

Hi @gustaff-weldon Could you please share your workflow or code snippet so that our engineers can review it and understand the problem better?

[hardikdr]

      - uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.sha }}

Still, host key verification fails in the next step in https://github.com/webfactory/ssh-agent

	Host key verification failed.
	fatal: Could not read from remote repository.

[whatwhywhenandwho]

[j-mie6]

Yes, companies should instead leave keys in a vulnerable state and potentially compromise people's data just so the CI runs still pass.

[whatwhywhenandwho]

Yes, companies should instead leave keys in a vulnerable state and potentially compromise people's data just so the CI runs still pass.

It's none of anybody's business what we do with our CI/CD and why we need it. Who's paying who for a reliable service?

[j-mie6]

Not talking about your CI, I'm talking about GitHub's data integrity: it wouldn't be great if your companies source code/data was stolen by a man-in-the-middle attack enabled by a compromised key, would it? The world does not revolve around your CI

[whatwhywhenandwho]

Fair enough. But can a company that does this:

This week, we discovered that GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository.

actually be trusted? How does that even happen?

Sorry, I'm leaving this conversation, as it's not going anywhere.

Good thing they don't have nuclear buttons under control. Even Mr. Putin can control those.

[williamdes]

DNS lookup error: data does not exist Why does GitHub not have SSHFP records ?

[williamdes]

Replies in https://github.com/orgs/community/discussions/50919

[Akash1134]

Hi @williamdes Sorry about the trouble caused. I have shared this feedback with my engineering team to provide more details and will get back to you once I hear back from them. Thanks!

[williamdes]

Thank you, please reply on the above link or mention me :)
Unsubscribing, there is too much people talking on other items of this discussion

[Lehren]

Removed the old host key and added the new one, still getting

Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.121.3'

[ScottG489]

See if this comment above works: https://github.com/orgs/community/discussions/50878#discussioncomment-5414174

[Akash1134]

Hi @Lehren Sorry about the trouble caused. I have asked my engineering team to provide more details and will get back to you once I hear back from them. Thanks!

[kiafaldorius]

Late to this, but try this: https://github.com/orgs/community/discussions/50878#discussioncomment-5419003

[jzohrab]

I had this, and just deleted all of the 140.82.* lines from my known_hosts file. Those IPs are listed in the "meta" link at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses. For the next few pulls from my github repo, I got a warning: "Warning: Permanently added the ECDSA host key for IP address '140.82.x.y' to the list of known hosts", where x and y changed each time, but once the IPs were added the warnings stopped.

[eli-schwartz]

I am disappointed in GitHub's failure to engage in sensible security precautions here. Rotating host keys like this is dangerous, because it encourages people to think that it's normal to ignore the ssh warning that your connection may have been compromised.

THIS IS A PREVENTABLE PROBLEM. The openssh protocol extensions exist to make this work sensibly, sanely, securely. It's been nearly a decade.

GitHub -- please read this article: https://lwn.net/Articles/637156/

Implement hostkey rotation. Advertise multiple keys, so that in the future, if you have to decommission a single key, the others still work without user errors and without telling people to ignore scary warnings.

[eli-schwartz]

Sure, I get that this says terrible things about GitHub prod management policies and no one should ever have been in a position to know the secrets in order to leak them. I'll go even further and say that GitHub was, in fact, exploited. "But they're my employees, I trust them" is never an excuse to allow arbitrary people access to stuff they don't need for their job, and the handful of people that do have access to private keys should be security team and vetted for their ability to be proactive about avoiding these mistakes, among other key security requirements.

But I'm not focusing on that here, I'm focusing on the fact that even after the fact, GitHub's remediation strategies suck too. They can't even "gracefully recover and resolve to do better in the future".

[eli-schwartz]

The difference being the key loss is now silent

They do still need to publish a security warning on their blog, so people can double check that they are now secure. It helps tremendously if the tooling only requires you to get it right once.

If people fail to check other systems and then get first-time-hacked by a MiTM then this is possible regardless of the use of multiple keys. The only "benefit" of requiring all users everywhere to rebootstrap their chain of trust is that people who don't read the blog might totally fail to realize anything happened. I don't buy that as a good rationale to make people insecurely follow instructions to "ignore the scary warning".

[kiafaldorius]

It helps tremendously if the tooling only requires you to get it right once.

This is assuming they actually get it right... I agree with the sentiment to an extent, but many devs are busy people who just don't pay attention to something until it's forced to be in front of them. I don't have to the time to follow all security advisories of all the libraries and services I use on a day to day basis. I try, but it's always an ongoing hassle. Newer client versions might not be available in all systems/distros...so there's always that lag while everyone catches up.

I completely agree that the generic "run this command to fix this problem" is a bad issue here too. Caused by the same issue...some people just need to get back to work.

But GitHub definitely messed up terribly with this situation... all around. The fact that the only indication that something was wrong was an SSH failure, and I still don't see any security notice emails or anything about this from them is a bad sign. I had to search out to confirm a key change.

If there was no warning, I probably wouldn't have known about a rekey until days later when it reached the news cycle.

[eli-schwartz]

And there's still no warning on machines that started off with an ed25519 key because when they first connected, that's what was automatically negotiated fornthem (OpenSSH is convenient there).

I reiterate: doing the wrong thing as a remediation measure and claiming it's better that way because "the wrong thing" spawns an error dialogue seems incredibly wrongheaded. Spawning an error dialogue on one machine is not a reasonable mechanism to make people aware that they need to fix a second machine, because there is zero guarantee you will get any such warning.

and I still don't see any security notice emails or anything about this from them is a bad sign. I had to search out to confirm a key change.

GitHub deciding that only people who follow the blog deserve to know about security issues is a problem.

It is a problem that is unrelated to secure rotation, rotation works quite well in combination with sending emails.

I simply do not understand why you're arguing that there's a principled advantage to avoiding security enhancements because...

... security enhancements won't get in your face as a "replacement" for the failure to send out emails.

Maybe we should do the same thing everywhere else. I'm sure the CA system could use some new ideas for interactive failure modes.

[kiafaldorius]

I never said not to do it. I warned others to be careful if they go that route. It was literally my first sentence.

The link you posted even mentioned it was experimental at the time, and linked to multiple other sources that added caveats and security implications. Compatibility needs to catch up with clients capabilities. You can't set up something on server-side and just expect all clients to play nice, be properly updated and configured.

There are caveats to using additional host keys. Just look at the ssh man docs for UpdateHostKeys and the notes there. I didn't say don't do it or avoid it. I said to be careful--as with anything that focuses on security, proceed with caution. I gave an example of the first thing that came to mind of something to watch out for--admittedly not a very good example in retrospect.

The key rotation itself is a good thing. I even said it above. But in this case, since GitHub can't be trusted to notify users, I would rather have the warning here and go digging around for why than for it to have been swept under the rug.

If they had implemented this key rotation mechanism beforehand, it wouldn't have mitigated their loss of the private key...but it would have made it easier on the user base by, as you mentioned, not leading to this thread encouraging copy-pasting arbitrary commands. That I wholeheartedly agree with...especially now with examples of comments suggesting people install a new package to run some of the commands. heh

[kiafaldorius]

Removing the RSA host key causes a new key-exchange into ECDSA. Looks like they updated the server to defaults to make RSA last on the key negotiating list:

debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa

The issue now is if you connected before this with rsa, the ECDSA may have already been added, so you have two keys for the same IP.

Here's the workaround with regard to security:

First go here and pray to god that GitHub system repositories didn't get compromised: https://github.com/github/docs/blob/main/content/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints.md

Then run: ssh -vvv github.com

This gives you extended debug information for what ssh is trying to do. The juicy bits are the last few lines. Look to see that the keys being negotiated match the fingerprints shared in the github doc above. In my case, I see:

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
debug3: hostkeys_foreach: reading file "/home/stupidgithub/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/stupidgithub/.ssh/known_hosts:96
debug3: load_hostkeys: loaded 1 keys from github.com
debug3: hostkeys_foreach: reading file "/home/stupidgithub/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/stupidgithub/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.30.255.113
debug1: Host 'github.com' is known and matches the ECDSA host key.
debug1: Found key in /home/stupidgithub/.ssh/known_hosts:96
Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '192.30.255.113'
Offending key for IP in /home/stupidgithub/.ssh/known_hosts:1
Matching host key in /home/stupidgithub/.ssh/known_hosts:96

I confirmed the server host key matches the fingerprint displayed. Then I run this command to remove the offending ip: ssh -R "192.30.255.113" (Note: You may need another variant like: ssh-keygen -f ~/.ssh/known_hosts -R "192.30.255.113" depending on your environment. Obviously replace it with the correct path to your known_hosts.)

And then run it again, and if the new host lookup matches the same ip... ssh now works. Otherwise...repeat from the top and verify fingerprint for the new ip. It happened to me for 192.30.255.113 and 192.30.255.112.

Posting your private key publicly is a fucking colossal fuck-up.

[shawnwall]

This is the only thing that worked for me in the end, including the sed I found via hackernews. I'm on ubuntu 20.04:

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

[fireballpoint1]

I have been facing the following error since doing these 3 commands:

remote: fatal error in commit_refs
To github.com:[REDACTED]-org/[REDACTED].git
 ! [remote rejected] mayankBillingMarch -> mayankBillingMarch (failure)
error: failed to push some refs to 'github.com:[REDACTED]-org/I[REDACTED].git'

Any fixes for this ? I have already tried gc, pushing a new branch n all

[patrick-knight]

Hey y'all for those noticing
remote: Bypassed rule violations for refs/heads/main:

This is a new behavior we are rolling out to let admin know they are commit it a repo with branch protections in place and will bypass them based on their permission.

Here's the change log we shipped about this update.

This is unrelated to the SSH KEY change

[NumberChiffre]

Thank you!!

[bique14]

It worked for me.
YOU SAVED MY LIFE !!!! MANY THANKS

[khiav223577]

not working. get the error: curl: (23) Failed writing body (1068 != 1370)

[starinajes]

Hello. After updating the host key, I do not see the commit statistics for several days in my personal account. The commits were made in my name and email , but they still didn't get into the account statistics. What to do?

[imbradbrown]

Are there plans to update all of the ssh services to be under github.com? EG just did
ssh -T git@github.com and 140.82.113.4 was added. Believe there's a .3 as well but can't confirm that yet.

[guillebianco]

Can confirm. We've replaced the keys on Friday, everything appeared to be working fine but we've been having all kinds of (ongoing) issues throughout the day today.

[benjaminkohl]

I went through this last week and got it all working again after restarting my machine. But as of today, it is back to giving me the same messages when I try to perform a pull or push.

Warning: the RSA host key for 'github.com' differs from the key for the IP address '140.82.112.4'
Warning: the RSA host key for 'github.com' differs from the key for the IP address '140.82.113.3'

I don't think the instructions in that blog post that has been linked to umpteen times completely addresses this issue.

[Crescent-Saturn]

Try to clean your known_hosts which related to GitHub, and make the git fetch or git pull to update a new one. See the post just below.

[lolmaus]

How do I clean known_hosts? It only contains encrypted cotnent, I don't know which line is the offending one!

[airtower-luna]

The hostnames/IPs are hashed, not encrypted. Use the ssh-keygen -R command to handle that, it'll hash the hostname or IP you give it and delete matching entries from the known_hosts file. The blog post has an example with github.com, you can just replace the hostname with the relevant IP(s).

[lolmaus]

Thank you @airtower-luna!

[interglobalmedia]

@benjaminkohl I think everyone has their own set of issues. For example, I could not connect this morning at 8am when Github was down, but a little while later when githubstatus.com stated that everything was up and running again, I tried connecting, and I could. And later, i did not even have the "bypass" error I had been getting since I made the fix on Friday. So this is definitely NOT a "one size fits all" situation. And what is strange is that githubstatus.com right now is stating that all systems are operational, when that probably is not the case.

[interglobalmedia]

The bypass error does still show up (that particular repo did not have the main branch locked). It is just meant to remind you that that you had set that protection to the branch. I have been doing that to some repos for a while now, but getting the message when I push to the remote repo is new (since Friday, March 24, 2023). At least for me anyway.

[fescobar]

I removed completely the known_hosts file and when I pulled again just asked me to add the new host. I pulled again and it worked. Pushing is working too.

[Feuda]

worked

[burvilc]

Works for me, too. Issue is that it comes back, seemingly because it's hitting another server behind the load balancer. Workaround to edit known_hosts isn't a scalable solution.

[ChandraKAV]

That is what I did too. Removed GitHub record from known_hosts and did a pull again. It worked. Sent with Spark

…

On 28 Mar 2023, 1:31 PM +0530, Oluwapelumi Egunjobi ***@***.***>, wrote: Same with me — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[charlespsdowd]

This is still not working !

[Neodevils]

I know, this is off-topic but I wanted to fix your typing on the title.

GitHub doesn't have a gender. 😅

[Ruboka]

does the paragraph where Github put their new key have a missing CRLF at the end?
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

[ansergeyg]

Hey, can someone tell me please if it's ok to see one of github ip addresses on this website?

https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/140.82.121.3

Or it's really fraud?

[crisman]

No idea on that page, for the list of active github IPs see:
https://api.github.com/meta

For ssh access use the host key linked from be blog post above.

[ansergeyg]

@crisman , thank you. I suppose the ip is legit as it's in the range of registered ip addresses: 140.82.112.0/20

[mkduer]

After receiving the same REMOTE HOST IDENTIFICATION HAS CHANGED!error, I also followed the github blog details for removing the old host with the new one.

Afterward, I also saw the IP Address error others have mentioned:
...key for 'github.com' differs from the key for the IP address ...

I didn't enter yes on the prompt, and instead was able to resolve the issue by adding all three of the ssh keys referenced by github in their Authentication Documents into the known_hosts file. This includes the originally recommended ssh-rsa key along with ssh-ed25519 and ecdsa-sha2-nistp256 keys if this is helpful to others.

My guess is that the issue was because I was actually using the ed25519 encryption instead of rsa to start, but this is just a guess on my part.

[simoncpu]

I thought my connection was being intercepted. Whew.

[darinageo]

It would have been much appreciated if an official email was sent to notify us of this update.

[Mykola-Samchuk]

Hello.
I have a similar problem.
When I want to deploy using the command: npm run deploy
then I get an error
Host key verification failed.
fatal: Could not read from remote repository.
although the rest of the commands such as: git push, git commit,... pass well

[guypr]

Has this happened again? Me and several other users are getting the same error again

[airtower-luna]

There's no mention of anything of the sort on the changelog.

Is the key fingerprint you're seeing one of those published in the docs here? https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints If not, someone or something is messing with your connections and you should not continue connecting.

[guypr]

Sorry we resolved the issue, it was unrelated to any change in Github

[deepchy]

can you please help me what method you used as I am facing the same error and not able to resolved almost tried all ways on the internet.

[guypr]

The issue was due to a firewall configuration in our router, which went over all ssh requests

[saeid1994]

if you use mac (i do not if it is right way for linux or windows) :
open this file by vi : 'known_hosts'
for example : vi /Users/yourusername/.ssh/known_hosts
then remove all the lines that related to your github host
after removing it, open new terminal and run again by 'sshuttle' or 'ssh' but i'm using 'sshuttle' and it is okay

[martindubenet]

« after removing it, open new terminal and run again by... »

HI, I'm a macOS user.
At first I was confuse by what command you refer to when mentionning «run again».

So to avoid manually verifying GitHub hosts i kinda followed your instructions but instead of deleting the content of the file « ~/.ssh/known_hosts » I simply edited it by adding the 3 key entries (ssh-ed25519,ecdsa-sha2-nistp256 and ssh-rsa) listed as a code block in GitHub's SSH key fingerprints documentation. I added those below the ones I already had listed for other git repository providers.

Then, since I was trying to git clone a GitHub.com repo locally in the first place, i did just that and everything is now fine.