主机“ github.com (192.30.252.128)”的真实性无法确定

Github just made changes to their ip address infrastructure. You can read here for more details https://github.com/blog/1606-ip-address-changes . Also, I have never seen a problem like this before. Is you package.json containing a git depency cloned via ssh?

Try echo 'yes' | sudo npm install. This may solve your problem. If it does not, try cloning via HTTPS instead or download the module as a tarball instead, which can be done like this https://api.github.com/repos/username/reponame/tarball

Run ssh github.com and type yes and it should fail. Then run your command again. If not try ssh github.com again as they have multiple IP's and you might need all of them.

Run ssh -o StrictHostKeyChecking=no git@github.com in command prompt to add the authenticity to your known_hosts. Then you won't get the prompt the next time.

You sure you're not accidentally logged in as a different user (this happens to me when I sudo -s / login as root and forget my GitHub account isn't linked to that user).

Danger ahead, unless you actually don't care about secure communication with github on your local account

Ssh rightly complains that they can't make sure you are indeed connecting to github's server through a secure channel. That might be why github is recommending https access, which works out-of-the-box thanks to its public key infrastructure.

Now, you can have it work, but be aware that it involves caching a public key fingerprint which, if done incorrectly, provides an attacker permanent man-in-the-middle attack.

How to proceed safely?

Option 1 is use https url instead of ssh.

Option 2 is have ssh access work.

Okay, show me option 2

1. Do ssh -T git@github.com but don't just type "yes".
2. Check if the hash that is shown matches one of the hashed shown in https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/ (in your question it does, and see, the page is fetched through https for the same public key infrastructure reasons).

If the hash matches, then connection is indeed safe you can answer "yes" to ssh's question.

Okay, I checked and typed yes, how do I know it works?

Ssh will show something like:

Warning: Permanently added the RSA host key for IP address '192.30.252.128' to the list of known hosts.

After that, you will either see a message like

Permission denied (publickey).

which is good but shows that you need further configuration, or simply

Hi yourlogin! You've successfully authenticated, but GitHub does not provide shell access.

which means that all works well and you can retry your first operation.

Notice that if you retry the same ssh command, it should no longer ask the question.

I landed here because I was getting this error and not understanding why. It turns out I had a typo in my npm command:

npm install -P -E @angular/common @angular/compiler @angular/core @angular/forms
@angular/platform-browser @angular/router @angular/animations@ angular/platform-browser-dynamic

Notice how the end of the line reads @angular/animations@ angular/platform-browser-dynamic.

NPM interprets the last "package" as being a github repo and that is where the error comes from.

I know this does not actually answer the question but I put it up just in case anyone else encounters this by making a similar mistake.

If you have this type problem

The authenticity of host 'github.com (192.30.252.131)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:1d:52:13:1a:21:2d:bz:1d:66:a8.
Are you sure you want to continue connecting (yes/no)?

don't worry, follow these steps:

Step 1: yes [press enter]

then you'll get:

Please type 'yes', 'no' or the fingerprint:

Step 2: copy fingerprint and paste here [press enter ]

I was using npm ci but the package-lock.json file had a lot of git+ssh:// URLs which triggered this error message.

Bashed on the accepted answer here, I used a little sed script to replace all the ssh:// URLs with https:// URLs:

sed -i 's|git+ssh://git@github.com|https://github.com|' ./package-lock.json

I hope that may help some people in a similar situation.

This is a quick workaround. A more permanent solution would be to fix the URLs in the package.json file, in order to build an improved package-lock.json file.

I solved my problem by running

ssh-keyscan github.com >> ~/.ssh/known_hosts

in command prompt. This command will add authenticity to your known_hosts.

Stéphane Gourichon's 2016 answer mentions:

Do ssh -T git@github.com but don't just type "yes".

Check if the hash that is shown matches one of the hashed shown in "GitHub's SSH key fingerprints".
(in your question it does, and see, the page is fetched through https for the same public key infrastructure reasons).

Another way to check, this time programmatically, if the GitHub host keys match, is to use the GitHub API (Jan. 2022):

GitHub’s SSH host keys are now published in the API

The GitHub metadata endpoint (api.github.com/meta) now contains our SSH host keys.
(We'll continue offering host key fingerprints as well.)

{
// new entry
"ssh_keys": [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl",
"ecdsa-sha2-nistp256 >AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=",
"ssh-rsa >AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ=="
],
// existing entry
"ssh_key_fingerprints": [
"SHA256_RSA": "nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8",
"SHA256_ECDSA": "p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM",
"SHA256_ED25519": "+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU"
],
// ... rest of payload
}

These keys are in the OpenSSH known_hosts format for easy inclusion into existing known_hosts files.

This will make it easier to preconfigure systems which expect to connect via SSH.

For example, you can prime your CI runners with these keys before starting to fetch from GitHub.

The keys returned from the API include both SSH host keys that we're actively using, plus any that we're advertising via host key rotation for future use.

Currently, we're not offering any keys via rotation that aren't actively in use, but if we announce new host keys in the future, you can find them here as well during the rotation period.

See the meta API endpoint to learn more.

Just in case you stumble upon that in IntelliJ IDEA (or any other IntelliJ product), go to Version Control > GitHub and uncheck [✓] Clone git repositories using ssh.