On November 4, GitHub did something it had been warning about since September: it turned off two legacy SSH algorithms for a day. Not a warning banner. Not a deprecation notice in a changelog you never read. The algorithms simply stopped working, and anyone whose setup still depended on them got a failed connection instead of a push.

If your git push worked fine that day, good. That probably means you were never at risk. But the brownout was only a rehearsal. The same switch flips again on December 9, and on January 13, 2027, the old algorithms are gone for good. If you push code over SSH — and if you run any automation that does — now is the time to check, while the fix is still a five-minute job and not a 2 a.m. incident.

What actually changed

GitHub announced the change on September 22, and it has four parts:

  1. RSA signatures using SHA-1 are going away. In SSH terms, that is the ssh-rsa signature type, including RSA certificates that sign with SHA-1. SHA-1 has been known-weak for years; this is GitHub finally pulling the plug.
  2. The diffie-hellman-group-exchange-sha256 key exchange is going away. GitHub calls it slow and little used, and notes that advances in quantum computing could break it.
  3. New RSA keys must be at least 3,072 bits. Since October 14, any RSA key uploaded to GitHub — for login or for signing commits — has to be 3,072 bits or longer. The 2,048-bit default that older versions of ssh-keygen still produce gets rejected on upload.
  4. A post-quantum key exchange is now available. GitHub switched on mlkem768x25519-sha256, a hybrid that combines ML-KEM-768 with X25519, for SSH connections to github.com.

The schedule is what matters: brownouts on November 4 and December 9, permanent removal on January 13, 2027. One independent check of the first brownout found the old algorithms off from about 08:30 UTC to about 22:00 UTC on November 4, then back on. That is the whole point of a brownout — a controlled, temporary outage so you find your broken setups on a day you chose, instead of discovering them on the day the algorithms disappear forever.

The part most people get wrong

The headline that traveled around was "GitHub requires 3,072-bit RSA keys now," and a lot of people read that as "my RSA key is dead, I need a new one." That is not what GitHub said, and it is the most common misunderstanding in this whole change.

The 3,072-bit rule applies only to keys uploaded after October 14. Your existing RSA key keeps working — with one condition. Your SSH client has to sign with SHA-2, using rsa-sha2-256 or rsa-sha2-512 (defined in RFC 8332 back in 2018), instead of the old SHA-1 ssh-rsa signature. Any modern client does this by default. OpenSSH 7.2 and later, which is nearly a decade old at this point, handles it.

In fact, the group of people who can still hit the SHA-1 problem is smaller than it looks. Since March 2022, GitHub has only accepted SHA-1 signatures from RSA keys that were added before November 2, 2021. If your key is newer than that, your client was already forced onto SHA-2 signatures years ago. The people at real risk are running old keys on old clients — and the old clients are the actual problem.

Where the breakage really lives

If you are a developer on a current laptop, you are probably fine. The breakage lives in the places nobody looks at:

  • CI runners and build servers that were set up years ago and never updated, still running an ancient OpenSSH or an old Java SSH library.
  • Embedded devices and appliances with a bundled SSH client from 2019 that nobody can update without a firmware release.
  • Deploy scripts and cron jobs that push over SSH from a forgotten VM, using a key generated when 2,048-bit RSA was the default.
  • Old Git clients and IDE integrations that ship their own SSH implementation instead of using the system one.

GitHub published minimum client versions with solid RSA/SHA-2 support, and the pattern is consistent: if your tooling is from the last few years, you are fine; if it predates 2021, check it. The key exchange side is the second trap — a client that only speaks the removed Diffie-Hellman method fails no matter what key you give it.

The November 4 brownout was designed to smoke exactly these out. If something in your pipeline failed that day and nobody noticed, December 9 is your second warning. January 13 has no warning attached.

The post-quantum part is the quiet headline

Buried under the deprecation dates is the more interesting change: mlkem768x25519-sha256 is live on github.com. It is a hybrid key exchange — ML-KEM-768, the NIST-standardized post-quantum key encapsulation mechanism, combined with X25519, the elliptic-curve key agreement everyone already trusts. The two contributions are mixed to derive the session key, so the connection stays secure even if one of the two algorithms turns out to be weaker than expected.

This is the same hybrid pattern I use in my own messenger project, where ML-KEM-768 runs alongside a classical ECDH exchange. The idea is the same everywhere it shows up: do not bet the whole connection on the new algorithm before it has years of cryptanalysis behind it, and do not bet it on the old one either, because harvest-now-decrypt-later means today's traffic can be stored and broken later. Run both, and the attacker has to break both.

OpenSSH added support for this key exchange in version 9.9 and made it the default in 10.0, released in April 2025. So if you are running a current OpenSSH, you may already be negotiating a post-quantum key exchange with GitHub every time you push, without having changed a thing. You can check what your client actually negotiated:

ssh -v -T git@github.com 2>&1 | grep -i kex

If you see mlkem768x25519-sha256 in the agreed key exchange, your pushes are already hybrid post-quantum. If your client is older than 9.9, it will negotiate something classical instead, and upgrading OpenSSH is the whole fix. Nothing on the GitHub side needs to be configured — the server already offers it.

One honest caveat: this protects the key exchange, not the authentication. Your account is still authenticated by your Ed25519 or RSA key, and the post-quantum signature standards for SSH authentication are a separate, later conversation. Key exchange is where the harvest-now-decrypt-later risk lives, though, so it is the right place to start.

The five-minute check

Here is the whole audit, and it takes less time than reading this article did:

1. Confirm how you connect. If your remotes start with https://, none of this affects you. Check with git remote -v. Everything below is for SSH remotes only.

2. Check your key type. Look at ~/.ssh/ or run ssh-add -l. If your key is Ed25519, you are done with the key side — GitHub recommends Ed25519 for new keys wherever your platform supports it. If it is RSA, check its size: ssh-keygen -l -f ~/.ssh/id_rsa. An existing key of any size keeps working as long as your client signs with SHA-2, but if you ever need to re-upload it, it has to be 3,072 bits or more.

3. Check your client version. Run ssh -V. Anything reasonably current supports RSA with SHA-2, and 9.9 or later gets you the post-quantum key exchange too. If you are below that, update your client before you touch your keys — an old client with a brand-new key still fails.

4. Test the actual connection, verbosely. Run ssh -T git@github.com. Then run it with -v and look at the agreed key exchange and signature algorithm. What the handshake actually negotiates is the truth; what you assume your config does is not.

5. Generate a new key if you need one. For a fresh key, Ed25519 is the straightforward choice:

ssh-keygen -t ed25519 -C "your_email@example.com"

Upload the public key to GitHub, test it, and only then remove the old one. Never delete the old key before the new one is proven to work — that is how a five-minute job becomes a locked-out afternoon.

6. Hunt down the forgotten automation. This is the step people skip. Check deploy keys, CI runners, cron jobs, and any script that pushes or pulls over SSH. A key you generated in 2020 and forgot about is exactly the kind of thing the January 13 deadline is waiting for.

Why GitHub is doing it this way

The brownout pattern deserves a note, because it is good engineering and more projects should copy it. A hard cutoff date in a changelog is a promise that something will break for someone who did not read the changelog. A brownout converts that into a rehearsal with a known date and a recovery: the old algorithms come back at the end of the day, and the people who broke get a concrete error message pointing at a concrete fix, while there is still time to apply it.

The November 4 brownout already happened. If nothing of yours broke, that is real evidence, not luck — it means your clients and keys already speak the modern algorithms. If something did break and you worked around it by waiting for the algorithms to come back, that workaround expires on January 13.

The bigger picture is that this is what the post-quantum migration looks like in practice. It does not arrive as one dramatic flag day. It arrives as a series of unglamorous, well-signposted changes: a minimum key size here, a retired hash function there, a hybrid key exchange quietly becoming the default. NIST's transition report sets the end of the road at 2035; GitHub just moved one very widely used service a step down it. The developers who stay ahead of it are not the ones reading every standards document. They are the ones who run ssh -V when someone tells them to, and fix the old runner before the deadline instead of after it.

December 9 is five weeks away. January 13 is nine. Check now, while it is still boring.

Sources: GitHub Changelog announcement, September 22, 2026; GitHub's published SSH client minimum versions; OpenSSH 9.9 and 10.0 release notes; NIST IR 8547 (final, October 2026).