GitHub announced a set of SSH security changes on 22 September 2026, and the first phase took effect on 14 October. Newly uploaded RSA keys must now be at least 3072 bits, for both authentication and signing. On the same date GitHub enabled the hybrid post-quantum key exchange mlkem768x25519-sha256 on github.com and on GitHub Enterprise Cloud with data residency, except the US region.
The harder part is still ahead. GitHub plans brownouts of the SHA-1 ssh-rsa signature type and the diffie-hellman-group-exchange-sha256 key exchange on 4 November and 9 December 2026, then removes both on 13 January 2027.
What's affected
Only Git over SSH, plus the unauthenticated Git protocol on GitHub Enterprise Server. Remotes that start with https:// are not affected.
The schedule from GitHub's changelog:
| Date | Change |
|---|---|
| 14 Oct 2026 | New RSA keys must be 3072 bits or more. mlkem768x25519-sha256 enabled. |
| 4 Nov 2026 | First brownout of ssh-rsa (RSA with SHA-1) and diffie-hellman-group-exchange-sha256 |
| 9 Dec 2026 | Second brownout |
| 13 Jan 2027 | Both removed |
On GitHub Enterprise Server the changes arrive in 3.25, except ML-KEM key exchange, which arrives in 3.24.
Existing RSA keys shorter than 3072 bits keep working. What matters for them is the signature algorithm. Clients must sign with SHA-2 (rsa-sha2-256 or rsa-sha2-512). GitHub lists the minimum versions with reliable RSA SHA-2 support by default:
- OpenSSH 7.2p1
- JSch 0.1.66 (the mwiede fork)
- TeamCity 2021.2.3
- Go SSH 0.16.0
- libssh2 1.11.0
- PuTTY 0.82
The usual casualties are not developer laptops. They are old build agents, embedded Git clients in CI and deployment tools, Java apps on the original unmaintained JSch, and appliances that pull config from Git.
How to check if you're exposed
Check a client's negotiated algorithms against GitHub:
ssh -vT git@github.com 2>&1 | grep -E "kex: algorithm|server-sig-algs|Server accepts key"
A modern OpenSSH should show mlkem768x25519-sha256 or another modern kex, and accept your key with rsa-sha2-256 or rsa-sha2-512.
Simulate the removal ahead of the brownout by forcing the old signature type off:
ssh -o PubkeyAcceptedAlgorithms=-ssh-rsa \
-o KexAlgorithms=-diffie-hellman-group-exchange-sha256 \
-T git@github.com
If that fails where a plain ssh -T git@github.com works, the client depends on algorithms that are going away.
Find Java services on the old JSch:
mvn dependency:tree -Dincludes=com.jcraft:jsch
# Old: com.jcraft:jsch. Maintained fork: com.github.mwiede:jsch
Check RSA key sizes you plan to upload:
ssh-keygen -lf ~/.ssh/id_rsa.pub # first number is the bit length
What to do now
-
Generate new keys as Ed25519. GitHub recommends it for new keys, and says Ed25519 and ECDSA keys will keep working indefinitely.
ssh-keygen -t ed25519 -C "ci-runner-prod-01" -
If you need RSA for other systems, use 3072 bits or more.
ssh-keygen -t rsa -b 4096works. -
Upgrade old SSH clients to at least the versions above. For Java, replace
com.jcraft:jschwith the maintainedcom.github.mwiede:jsch. -
Watch 4 November. Treat the first brownout as a free test. Have CI owners watch for SSH failures that day and log which systems broke.
-
Inventory deploy keys and machine users. Rotating a deploy key to Ed25519 is the moment to check whether it still needs write access.
-
For GitHub Enterprise Server, plan the 3.24 and 3.25 upgrades with the same client checks.
Why it matters
Deprecations like this are a supply chain event. A build agent that can't fetch source on 13 January is an outage, and the fix often lands in a rush on a shared credential nobody has looked at in years. The brownouts exist so you can find those systems before the removal.
The post-quantum piece is quieter but important. mlkem768x25519-sha256 combines ML-KEM with X25519, so a session stays protected as long as either holds. It addresses "harvest now, decrypt later" collection against Git traffic, and it needs no action from users: clients that support it use it, and older ones fall back.
SSH keys are also identity. A deploy key or machine user key with write access is a credential to your source, and this change is a good reason to audit them.
Try it yourself
Run the forced-algorithm ssh -T command above from each class of system that clones over SSH: a laptop, a CI runner image and one deploy server. Any failure is a system to fix before 4 November. To make the check part of every pipeline, the demo below shows how CI/CD actions can run checks like this automatically.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to replace my existing 2048-bit RSA key?
No. The 3072-bit rule applies to newly uploaded keys. Existing RSA keys keep working as long as your client signs with SHA-2, which most modern clients do by default.
Are HTTPS remotes affected?
No. GitHub says remotes starting with https:// are not affected by these SSH changes.
What do I need to do for post-quantum key exchange?
Nothing. Clients that prefer mlkem768x25519-sha256 use it by default, and older clients fall back to an existing algorithm.
