It could be worse, the user has the old rsa host key present alongside newer ed / ecdsa keys, they may never rotate out the rsa one. A future mitm simply only advertises the rsa key, and mitm passes.

Users will need to actively remove the old rsa key in order to be safe. It's my first question, and a colleague suggested that they believe that the private key was not seen, however, I don't see that in the post - unless I'm missing it - and I really want this stated very clearly somewhere.

I tested this and on a new enough OpenSSH client, the RSA key gets replaced using the mechanism described here: https://lwn.net/Articles/637156/ (if you connect using a key other than RSA).

To be honest, I'd expect something like this to be mentioned in the announcement.

Assuming the user connects to Github first instead of a MitM attacker spoofing Github.

> Users will need to actively remove the old rsa key in order to be safe

Yea that is my read on it as well. If that is true this is much more severe than the blog post suggests.

Unless they can also hijack the github.com domain, no.

That’s not that hard tbh. So many attacks.

But if you are doing git operations using SSH instead of HTTPS then you aren’t checking domain certs?

It's not about the certs. To execute a man-in-the-middle attack the attacker has to literally put themselves in the middle of the route your packet takes to get to github's servers and intercept it.

Sure, there are many ways an attacker can do that. Not trusting your IP transit is kind of the whole reason for encryption in the first place.

1. Various DNS hijacking and cache poisoning attacks 2. three letter agencies in meet me rooms 3. Exploited/hacked routers 4. Wifi hot spots