GitHub suddenly rejected my SSH key (the fix was a .pub file?!)
59 points by GLaDER
59 points by GLaDER
Same issue.. observing it for last 4 hours. It is already mentioned on https://www.githubstatus.com/incidents/g40zcbvchny4
I had an issue just a few weeks ago where I rotated some SSH keys, but I didn't remove the existing .pub files which were ignored in Git. I tried to SSH in with these new keys but they just would not work. I eventually enabled a bunch of debug flags and it took me a long time to realise that my SSH client was sending the old fingerprint. I had no idea OpenSSH read .pub files at all - all these years I've just assumed they're completely redundant.
I had this issue today as well! Our CI server could seemingly no longer connect to github.com.
Ended up rotating the key to a proper ed25519 key and it worked again. This key still does not have a companion .pub key so i have no clue why this worked
I was mostly concerned about some sort of compromise when my key stopped working out of the blue... good thing GitHub themselves seem to be on it now.
We just faced the same issue today. There's no announcement from GitHub, as far as I know, that they planned to change their SSH authorization behavior.
I don't expect that they planned it.
Thank you! I'd just started looking at this when I saw the post pop up in #lobsters, you saved me so much time.
I had a issue where I lost my password and didn't have my recovery keys. I was put through some account recovery process that used my ssh key. GitHub had also decided that my ssh key "expired" and so I lost access to my account entirely.
Wow, I don't think i have had a .pub file in 7-8 years, i hope it's fixed before i need to use github at some point
If "both flows are legal", why does the probing flow exist at all? Doesn't that just invite this kind of weirdness? Or, since you can generate a public kry from the private key anyway, why doesn't ssh do this automatically?
It’s for situations where the private key isn’t immediately available, eg because it’s encrypted or stored on a hardware security token: ssh tries to find out from the server which keys might work, so it doesn’t bother asking the user to pointlessly decrypt keys that will definitely fail to authenticate.
There are some odd side-effects of this behaviour, eg https://github.com/FiloSottile/whoami.filippo.io so it makes sense to allow a client to attempt authentication in a manner that requires the server to know the client’s public key beforehand, in case the user connects to the wrong server by mistake.
Interestingly, my work Office 365 account unexpectedly stopped working today, for the first time in 5 years.
Maybe something got compromised at Microsoft and they had to re-salt everything again? Or maybe it’s only for Europeans, because of the recent Chat Control 1.0 vote?
The connection termination service at GitHub has nothing whatsoever to do with M365 account auth. I’m 5+ 9s confident that this is a coincidence. (I’m perhaps uniquely qualified to assert this, being one of just two people (to my knowledge) who has worked both in Git Systems @ GitHub and on the Office/M365 family of products at Microsoft 🤣)
Edit to add: like, so disconnected that even IF this were related to some policy or technical change that applied equally to both services, it’s vanishingly unlikely they’d both land on the same day.