GitHub Just Broke SSH. Everyone Thinks It’s a Bug. It’s Not.

You’re pushing code. It’s 2 AM. The deadline is in six hours. And GitHub — the platform that literally hosts the infrastructure of modern civilization — just told you your SSH key is invalid.

Nothing changed. Your private key is right there. It’s worked for years. But now, suddenly, GitHub wants something it never asked for before: your public key file.

Wait, what?

Since when does SSH need the public key on the client side? That’s not how SSH works. That’s never been how SSH works. The private key authenticates you. The public key lives on the server. This is Cryptography 101, taught on day one of every security course on Earth.

And yet, here we are.

The most dangerous bugs aren’t the ones that crash your system. They’re the ones that look exactly like a deliberate design choice.

Here’s what happened: a developer named Thorsell documented this exact scenario. GitHub started rejecting SSH connections from keys that didn’t have a corresponding .pub file sitting next to the private key on the local machine. No announcement. No migration guide. No deprecation notice. Just… silence, followed by access denied.

The immediate reaction from the community was predictable: frustration. One commenter summed it up perfectly — “Wish they’d fix what’s broken, not fuck with stuff that works.”

And that’s the instinct, right? When something breaks that shouldn’t break, we assume incompetence. We assume some engineer shipped a half-baked change on a Friday afternoon. We assume it’s a bug.

But stop for a second. Think about who GitHub is. They’re not some startup scrambling to ship features. They’re the largest code host on the planet, owned by Microsoft, with a security team that could staff a small university. They don’t accidentally change SSH authentication behavior.

When a company with 100 million developers silently changes the rules of authentication, you don’t have a bug. You have a policy.

So what’s the actual play here? Think about it from a security architecture perspective. If GitHub requires the public key file to be present on the client, they’re enforcing something subtle but powerful: key pair integrity.

Here’s the scenario they’re likely trying to prevent: a developer generates a private key, uploads the public key to GitHub, then later reuses that same private key with a different public key for another service. Or worse — someone takes a stolen private key and tries to use it without having the matching public key file. By demanding the .pub file, GitHub can verify that the key pair is complete, consistent, and hasn’t been tampered with or split across contexts.

It’s not a bug. It’s a quiet enforcement of key hygiene.

The best security measures are the ones nobody asked for and everyone hates. That’s how you know they’re working.

Now, is this good practice? From a security standpoint, absolutely. Key reuse is one of the most underappreciated attack vectors in developer infrastructure. If your private key gets compromised and it’s used across GitHub, GitLab, your production servers, and your CI/CD pipeline, you’ve just handed an attacker the keys to the kingdom.

But from a developer experience standpoint? It’s a disaster. SSH has worked the same way for nearly three decades. Developers have muscle memory baked into their fingers. Scripts, CI pipelines, deployment automation — all of it assumes that SSH just works with a private key. Changing that behavior silently, without documentation, without a heads-up, without even a helpful error message, is the kind of move that erodes trust.

And that’s the real tension here. GitHub is right on the security. They’re wrong on the communication.

You can have the best security policy in the world, but if you deliver it as a 2 AM lockout, you’ve just trained a generation of developers to distrust you.

So what should you do? First, check your SSH setup. If you have a private key without a corresponding .pub file, generate one now with ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub. Don’t wait for GitHub to lock you out. Second, audit your keys. If you’re reusing the same key across multiple services, stop. Generate separate key pairs for each service. It’s annoying, but it’s the right call.

And third — and this is the one nobody wants to hear — start expecting this kind of silent enforcement from every platform you depend on. The era of “SSH just works” is ending. Not because the protocol is broken, but because the threat landscape has evolved past what the protocol was designed to handle.

GitHub didn’t break SSH. They just decided that the old way of doing things wasn’t good enough anymore. And they didn’t ask your permission.

The platforms that host our code are no longer just infrastructure. They’re policy makers. And they’ve stopped asking before they change the rules.