Every time I push to my repo, a new ECDSA host key is for IP address is permanently added

[cjacqo]

Hello,

I have set up ssh on my device, and can push to my repo successfully, but every time I do, I get this warning:

Warning: Permanently added the ECDSA host key for IP address '140.00.xxx.x' to the list of known hosts.

My known_hosts file is then updated with the new IP with a fingerprint that I do not recognize. The IP address that proceeds each fingerprint increments/decrements by one number for each new row that is added to the file, but the fingerprint that I am not recognizing stays the same.

I have tried to add the following to my ~/.ssh/config file:

Host * IgnoreUnkown UseKeychain UseKeyChain yes

Also, when I run ls -al ~/.ssh, I get a total of 48, even though there are only 5 "unique" IP addresses (exactly how many commits/pushes I have made). After creating my key following the GitHub docs, I ran the same line in the terminal with a result of 0 before cloning and working on my repo.

Is this something that I should be concerned about?

[cjacqo]

I found this which suggests that the 140 IP is apart of the subnet mask that covers the range 140.82.112.1 - 140.82.127.254. I believe this suggests that my warning is nothing to worry about?

[airtower-luna]

GitHub has multiple IP addresses, and if SSH encounters a new one but the fingerprint still matches one known for the hostname you get that warning. So as long as the fingerprint is one of the published ones it's nothing to worry about. 😺

However you should remove the line you've added to ~/.ssh/config, that has nothing to do with host key checking. 😅

[simkimsia]

@tiagogandarezff answer is the most helpful.

If you have issue with jq not working, you probably need to install it like I did.

[w-biggs]

Even after doing this the message appears every time I use git. There must have been some old keys in known_hosts or something, because simply clearing my entire known_hosts fixed the issue for me.

[ValeriyTen]

I had the same problem. I got it right by doing:

1. ssh-keygen -R "< IP >" (in your case 20.207.73.82)

2. ssh-keygen -R github.com

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

These two last commands I saw them in the already shared github page

Thank you, removing IP record from known_hosts resolved my problem. Were executing steps 2 and 3 following Github instructions, but didn't see IP record myself on top of github.com one.

[prathamesh-gharat]

@ValeriyTen I had already done that, but in my case I noticed today that there was another IP involved.

For me, the github.com IP is rotating between, 20.207.73.82 and 140.82.121.4 .. after removing the entry for 140.82.121.4 the issue has finally been resolved for good. Thanks!

[joeflack4]

None of this is unfortunately working for me. Still getting this message multiple times when I pull, from just 1 particular repo, and it has multiple submodules.

[Go-450]

How can I SOLVE THIS PROBLEM

[airtower-luna]

As I mentioned above, the different IP addresses aren't a problem, as long as the key fingerprint is correct.

[KjellMorgenstern]

Possible explanations for incorrect fingerprints:

• the key was updated, but not yet all servers behind that IP have it.
• the connection is intercepted, the IP is answered by a machine that is not github. Which would pose a security thready to automated deploys (e.g. deploying a website from github source. Because now, whoever runs that machine, is in control of what is going to be deployed)
• there is still an outdated RSA in the known_hosts list

The latter is a reason to not ignore host key checks for automated deploys. Instead, I'd suggest to manually add the key once, and store it in your container.

I think the fingerprint is not correct right now, because it changes for successive requests to the same IP.
It currently looks like every time a new ECDSA host key needs to be added, no matter if the IP address was already added before.

git fetch

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

-> type yes

git fetch

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

Sometimes the IP address is 140.82.121.4 , but the issue is the same.

Edit: added one more reason to 'possible explanations', thx @blzzua

[airtower-luna]

If you get a different key each time that looks fishy to say the least. And the ECDSA key wasn't changed in the recent incident.

Check if the key you're seeing is one of those mentioned in the documentation. If yes, the key in your known_hosts file is outdated (or otherwise wrong) and you should replace it with those from the docs. If not, something is messing with your connection and you should definitely not type "yes" when asked if you want to continue connecting.

[blzzua]

i had same problem.
different rows of matching key in known_host file was hashed and not hashed versions. it was because i accumulated some records with HashKnownHosts=yes options (default) and soon i added HashKnownHosts no to my config.

just remove record with hashed hostname in /home/user/.ssh/known_hosts:18

[bmacphee]

Since github recently changed their RSA key, this might be helpful to clean up your known_hosts file.

for ip in $(for i in $(seq -f "140.82.%g.%%g" 112 127); do seq -f $i 1 254; done); do ssh-keygen -R $ip; done

(Assuming the IP range is as stated in this thread.)

This would let you keep hashing of known_hosts enabled and just start using the new public key without being prompted every time you connect to a different IP.

[lee-lindley]

Followed the instructions in that 3/23/2023 blog post and am still getting the issue today. I was not getting it a few weeks ago that I recall, but I suppose it could have been broken since March.

[lee-lindley]

I added HashKnownHosts = no to my ~/.gitconfig, then followed the isntructions in the blog post (but also removed the IP address the error message was reporting). Once I had done ALL of that, the error stopped occurring (for now).

[bmacphee]

Wow, some new activity in this discussion since posting my comment. Here's another recap in case it helps:

The best procedure is to follow the blog post first, but the ssh-keygen -R github.com step is not quite enough for most people. ssh also remembers all IP addresses that github.com resolved to every time it connects. You should ssh-keygen -R all of those, but because the records in known_hosts are hashed, you have to "guess" which ones are in there by telling it to remove every IP that might be in there. Something similar to the bash command above can help you do that.

More details:

Note my assumption about the IP range. It might be incorrect given some people have observed other IP ranges. It could be a different range for different parts of the world depending on how github's global infrastructure works?

The IP range I referred to originally:
https://github.com/orgs/community/discussions/27405#discussioncomment-3265908

Keep in mind that the known hosts file has a record of any IP address you may have connected to previously among many, and the error you get is only going to complain about one mismatch at a time. Disabling hashing of that file will make it so that future entries are easier to identify but all previously entered ones will still remain and could still cause the error if they are not removed. If you find other IPs not in the range, you can potentially clean those up with a similar loop. Someone mentioned 20.207.73.82 - is there a range associated with this one too?

Generally bad ideas:

• StrictHostKeyChecking off
• removing the known_hosts file
• ignoring security warnings

[bmacphee]

HashKnownHosts = no also only helps solve future problems, and won't help in this particular instance, as far as I know. It's not ideal from a security perspective, but also not on the same level as completely ignoring security.

[lyan-artur]

thanks

[doronbehar]

Perhaps not strict as some other solutions in this thread, but this addition to ~/.ssh/config was rough :

Host 140.82.1*.*
  StrictHostKeyChecking off

[airtower-luna]

That disables an important security feature though that prevents attackers from impersonating the GitHub servers. Deleting old keys and adding the known-good keys is the safe solution. ⚠️

[farazirfan47]

Remove the cached key for "'140.00.xxx.x" on the local machine:
ssh-keygen -R '140.00.xxx.x

[flipmcf]

For those on the 'simple' side (the kind way of saying 'dumb') both the hostname 'github.com' and any IP you may have ever encountered that results from a lookup of 'github.com' is stored in your known_hosts.

Note, the only reason you are doing this is because you have been alterted by github.com that their keys rotated. If you ever encounter this, you always should reach out to the host and ask if something really did change. If it didn't change, then consider yourself at risk until you can determine otherwise. Knowing that github.com has changed their keys, you now proceed with the below instructions feeling reasonably safe.

This is like getting a certified, potentially dangerous package of chocolates with a note "just eat this!" from "Jane Smith at 123 Main St.".
* But you never heard of "Jane Smith" in your life.
* However, you then discover that your friend "Jane Doe" got married, changed her name and address.
** This is now a good time to update your address book for friends who you trust and accept and eat chocolate from.

So, once you got passed the MITM attack with ssh-keygen -R "github.com" or manually removing the offending line, you will be left with the ip addresses.

Rather than predicting all the IP addresses you have ever encountered while asking for github.com, just ssh-keygen -R "<ip address>" whenever you get the ECDSA host key for 'github.com' differs from the key for the IP address '<ip address>' warning.

You should only have to do this two, maybe 3 times, depending on what your computer has seen in the past.

me:
$ ssh-keygen -R "140.82.113.4"
$ ssh-keygen -R "140.82.113.3"

and it stopped.

$ ssh-keygen -R "20.207.73.82"
Just because someone else mentioned it above in this thread, but that's a bit risky trusting anonymous posters on the internet.

Removing your entire known_hosts to solve this is not optimal, because it's analogous to clearing out all your contacts from your phone because one person's phone number changed.

[Jeroen-editing]

So if you get this warning:

Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '...'
....
Are you sure you want to continue connecting (yes/no)?

And you did all the other steps in the documentation correct.
You just need to remove those IP-addresses from the error-message with: '$ ssh-keygen -R ....' ?

Just checking if my English is still good enough ;)

Thanks

[flipmcf]

yes. you got it. And your English is spot-on.

[weichtg3]

For me, the 3 steps noted above (and here) had to be run twice. Ran them once and git pull still the error. Ran them again, and so far all git commands are clean (knock on wood)

ssh-keygen -R "< IP >" (in your case 20.207.73.82)

ssh-keygen -R github.com

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

[weichtg3]

Disregard... it came back later that day.

[ainoneko]

GitHub recommends to ignore security warnings.
Is it the same GitHub that has started enforcing 2FA recently?

[flipmcf]

can you link to where github recommends to 'ignore security warnings'?

I think 'ignore security warnings' is a pretty loaded statement and very broad. Never ignore security warnings. (unless you're doing npm, but that's another big problem) This thread is only specific to using ssh / ssl on the command line, and very specific to github's ssl keys, so when you do a ssh push or fetch to a git@github.com:PROFILE/reponame and it complains at you.

As for 2FA - I get challenged logging into the website, but from the command line I don't get a 2FA challenge. I think GPG digital signatures are the way to go there, but that's quite off topic from this thread.

read more here about GPG signing your commits: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification You become one of the 'cool kids' with 'verified commits' - and I have to admit, that's why I did it - just to look cool.

[slk500]

None of the examples above worked for me. But finally I've found the solution:
ssh-keyscan github.com >> ~/.ssh/known_hosts

[neverkas]

I read that github has multiple IP addresses but what I don't understand at all is why just the second command found the ip address from github that the first one couldn't.

• ssh-keyscan -t ed25519 github.com
• ssh -T git@github.com