4 ms·

> double check it is the expected value Not all of us are familiar enough with the SSH protocol to understand how to "double check the expected value"? Where c

by yosito 4y ago

> double check it is the expected value Not all of us are familiar enough with the SSH protocol to understand how to "double check the expected value"? Where can I determine what the expected value should be?

Gravyness 4y ago
Run "ssh -T git@github.com" command. It should error like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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. Note that the SHA256 present there matches perfectly the one github send. If you don't remember the very first time you connected to github you also had to accept the key. The warning above shows up because the server is saved as a different RSA, for the SSH client it seems that someone setup a server for github but has a different key, which could mean someone is trying to trick you into connecting into the wrong server. This could also mean that github changed their RSA key which is why they published this article.
- pbhjpbhj 4y ago
  The fingerprint is a hash of the key, so in theory -- say with a quantum computer -- I could create a key that's different and provides a hash-collision. Is that right? It would just take many ages of the universe, at present, to calculate a collision, right?
  - 8organicbits 4y ago
    There's a narrow window for that attack. The fingerprint is only used on the first connection, for manual verification. Any later connections would check the ~/.ssh/known_hosts which has the full public key. If you somehow can MITM an SSH connection on the first connection, you can probably use any key. Most people don't check the fingerprint. But you are correct, computing an SSH key with a collisionwis expected to take an infeasible amount of time/energy with current understanding of crypto and available computers.
Dylan16807 4y ago
Look for the part of the article that says "the following message" Or the parts below it about updating and verifying in other ways.
yetanotherjosh 4y ago
A key part of avoiding MITM is to get the values from an authoritative origin, not comments on HN, so the link is here: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints https://docs.github.com/en/authentication/keeping-your-accou... Yes, this assumes the github-hosted docs and your SSL connection to them are not also compromised, but it's far better than not checking at all.

by yosito 4y ago

Gravyness 4y ago

Run "ssh -T git@github.com" command. It should error like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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. Note that the SHA256 present there matches perfectly the one github send. If you don't remember the very first time you connected to github you also had to accept the key. The warning above shows up because the server is saved as a different RSA, for the SSH client it seems that someone setup a server for github but has a different key, which could mean someone is trying to trick you into connecting into the wrong server. This could also mean that github changed their RSA key which is why they published this article.

pbhjpbhj 4y ago
The fingerprint is a hash of the key, so in theory -- say with a quantum computer -- I could create a key that's different and provides a hash-collision. Is that right? It would just take many ages of the universe, at present, to calculate a collision, right?
- 8organicbits 4y ago
  There's a narrow window for that attack. The fingerprint is only used on the first connection, for manual verification. Any later connections would check the ~/.ssh/known_hosts which has the full public key. If you somehow can MITM an SSH connection on the first connection, you can probably use any key. Most people don't check the fingerprint. But you are correct, computing an SSH key with a collisionwis expected to take an infeasible amount of time/energy with current understanding of crypto and available computers.

Dylan16807 4y ago

Look for the part of the article that says "the following message" Or the parts below it about updating and verifying in other ways.

yetanotherjosh 4y ago

A key part of avoiding MITM is to get the values from an authoritative origin, not comments on HN, so the link is here: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints https://docs.github.com/en/authentication/keeping-your-accou... Yes, this assumes the github-hosted docs and your SSL connection to them are not also compromised, but it's far better than not checking at all.