> - Most users don't password protect their SSH keys, but they often have a password manager with a master password that they can keep HTTPS token in.
Are there password managers that actually seamlessly do that? GitHub's official docs (https://docs.github.com/en/authentication/keeping-your-accou...) for example recommends using the GitHub CLI to cache your authentication token for you and as far as I can tell the token is stored unencrypted (https://github.com/cli/cli/issues/1773), unlike SSH keys which should be encrypted behind a password. If you don't do this you have to enter your password every single time you use you Git, which is not good even if you have a password manager (it adds steps, and passwords aren't great to begin with because you send them in plain text to the server and it is why Apple etc are moving away from password-based authentication for websites).
> - Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys...
I think the key issue here is this really shouldn't have happened. There is no reason why GitHub couldn't secure their SSH private key just like their TLS key.
---
Edit: Thinking more about it, I think the situation would have been much worse if GitHub leaked a TLS key instead.
With SSH, an attacker who stole GitHub's private SSH key actually *cannot* MITM the user. They can pretend to be GitHub to the user, but they cannot pretend to be the user to GitHub, because with SSH both sides have a private/public key known to the other side. In a normal usage scenario, it would actually take some social engineering to do a real attack, because a simple Git fetch from the attacker would fail when trying to fetch a private repo (since the attacker does not have the permission to fetch it from GitHub).
With HTTPS, under current setups of username/password or an auth token, the user has no real way to protect themselves from a MITM attack. The token isn't a private key as it's shared directly to the server. That means the attack could actually MITM the server/user connection and do much much more damage.
Are there password managers that actually seamlessly do that? GitHub's official docs (https://docs.github.com/en/authentication/keeping-your-accou...) for example recommends using the GitHub CLI to cache your authentication token for you and as far as I can tell the token is stored unencrypted (https://github.com/cli/cli/issues/1773), unlike SSH keys which should be encrypted behind a password. If you don't do this you have to enter your password every single time you use you Git, which is not good even if you have a password manager (it adds steps, and passwords aren't great to begin with because you send them in plain text to the server and it is why Apple etc are moving away from password-based authentication for websites).
> - Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys...
I think the key issue here is this really shouldn't have happened. There is no reason why GitHub couldn't secure their SSH private key just like their TLS key.
---
Edit: Thinking more about it, I think the situation would have been much worse if GitHub leaked a TLS key instead.
With SSH, an attacker who stole GitHub's private SSH key actually *cannot* MITM the user. They can pretend to be GitHub to the user, but they cannot pretend to be the user to GitHub, because with SSH both sides have a private/public key known to the other side. In a normal usage scenario, it would actually take some social engineering to do a real attack, because a simple Git fetch from the attacker would fail when trying to fetch a private repo (since the attacker does not have the permission to fetch it from GitHub).
With HTTPS, under current setups of username/password or an auth token, the user has no real way to protect themselves from a MITM attack. The token isn't a private key as it's shared directly to the server. That means the attack could actually MITM the server/user connection and do much much more damage.