GitHub SSH Changes: What Developers Need to Update Before October

GitHub is changing the cryptography used by Git over SSH, and the first deadline arrives on October 14, 2026. New RSA keys uploaded after that date must be at least 3,072 bits, while GitHub is also preparing to remove SHA-1-based RSA signatures and an older Diffie-Hellman key-exchange method. 

The changes are unlikely to affect most developers using a current SSH client, but they can expose old libraries inside build servers, deployment systems, CI runners, or other development tooling. GitHub is also adding mlkem768x25519-sha256, a hybrid post-quantum key-exchange method, bringing its Git hosting infrastructure closer to the direction already taken by modern OpenSSH.

GitHub is retiring two older SSH mechanisms

The first change concerns ssh-rsa, the SSH signature type that uses the SHA-1 hash algorithm. SHA-1 has long been considered too weak for modern cryptographic use, so GitHub is removing support for RSA signatures that rely on it. This does not mean that every RSA key is suddenly invalid: an existing RSA key can continue working when the SSH client uses the newer rsa-sha2-256 or rsa-sha2-512 signature algorithms. 

GitHub is also removing diffie-hellman-group-exchange-sha256, an older key-exchange mechanism used to establish the shared secret that protects an SSH session. GitHub describes it as slow and little used, while modern SSH implementations have stronger alternatives available. The practical result is that developers with old SSH libraries may see connection failures even though their Git repository, credentials, and server configuration have not otherwise changed. 

New RSA keys will need 3,072 bits

Starting October 14, GitHub will require newly uploaded RSA SSH keys to be at least 3,072 bits. The requirement applies to both signing and authentication keys. Existing RSA keys are not automatically invalidated by this particular change, so a developer who already has a smaller RSA key does not need to replace it solely because the October deadline arrives. 

There is an important distinction here between key size and signature algorithm. A 2,048-bit RSA key can still use SHA-2 signatures if the SSH implementation supports them, whereas GitHub's new 3,072-bit rule concerns the size of RSA keys newly uploaded to the service. GitHub recommends Ed25519 for new keys where possible, while retaining RSA as an option when compatibility with another service requires it. 

Most current SSH clients should already be ready

GitHub's compatibility list puts OpenSSH 7.2p1, PuTTY 0.82, libssh2 1.11.0, Go SSH 0.16.0, and TeamCity 2021.2.3 among versions that can robustly use RSA with SHA-2 under their default configurations. That is why this change is more likely to expose old infrastructure than ordinary developer laptops. A workstation that has been regularly updated may continue connecting without any visible change. 

The hidden risk is software that embeds its own SSH implementation. A developer might have a modern OpenSSH command on their laptop while an automated deployment tool, build agent, Java application, or older CI component still negotiates legacy algorithms. GitHub specifically identifies users connecting with a Git client over SSH and users of the unauthenticated Git protocol on GitHub Enterprise Server as the groups affected by the announced changes. Git remotes using HTTPS are outside this particular change. 

Post-quantum SSH is becoming part of GitHub's default path

The other half of the change moves in the opposite direction: GitHub is adding mlkem768x25519-sha256 for SSH sessions on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region. ML-KEM is a standardized post-quantum key-encapsulation mechanism, while X25519 is a widely deployed elliptic-curve key-exchange method. Combining them creates a hybrid exchange intended to retain protection from current cryptographic attacks while adding resistance to future quantum attacks. 

This is not a completely experimental direction in SSH. OpenSSH has supported post-quantum key agreement by default since OpenSSH 9.0, initially with sntrup761x25519-sha512. OpenSSH 9.9 added mlkem768x25519-sha256, and OpenSSH 10.0 made it the default scheme. GitHub's move therefore follows an established implementation path rather than inventing a separate cryptographic protocol for Git. 

The brownouts are where old developer tooling will show itself

GitHub has scheduled temporary brownouts for November 4 and December 9, 2026, during which the retiring ssh-rsa signature type and diffie-hellman-group-exchange-sha256 key exchange will be disabled. A brownout deliberately breaks the old path for a limited period, giving teams a chance to discover systems that still depend on it before permanent removal. 

GitHub's published schedule then lists January 13, 2026 as the permanent removal date, but that date conflicts with the September 2026 announcement and the November and December brownouts that precede it. GitHub's current announcement therefore contains an apparent date error; the page does not explicitly correct it to 2027. Developers should not treat the January year as confirmed until GitHub updates the schedule. The November and December brownouts are the concrete dates currently published for testing compatibility. 

What developers should check before the first deadline

The first check is the SSH client actually used by your development workflow, not merely the version installed on your personal computer. Run the relevant SSH client's version command on build machines, CI runners, deployment hosts, and other systems that push to or pull from GitHub over SSH. If an old library is embedded in another application, upgrading that application's SSH implementation may be necessary even when the operating system itself is current.

If you use an existing RSA key, check that your client negotiates rsa-sha2-256 or rsa-sha2-512 rather than the SHA-1-based ssh-rsa signature type. GitHub says an existing RSA key does not need to be regenerated simply because SHA-1 signatures are being removed. For a new key, GitHub recommends Ed25519 where possible; if RSA is required for compatibility, the new key should meet the 3,072-bit minimum after October 14. 

Teams should also test automated jobs during the scheduled brownouts rather than waiting for a permanent failure. A repository that works from a developer laptop can still fail from a legacy build runner, because the two environments may use completely different SSH libraries. That is the main practical lesson from this migration: the important question is not whether your computer supports modern SSH, but whether every machine and software component that talks to GitHub does.

HTTPS users do not need to change anything for this migration

If your Git remote starts with https://, GitHub says these SSH-specific changes do not affect that connection method. Developers using HTTPS therefore do not need to replace an SSH key or change their Git authentication because of this announcement.

For SSH users, the migration is mostly a compatibility check rather than a requirement to rebuild every credential. Modern clients should negotiate the stronger algorithms automatically, existing RSA keys can continue working with SHA-2 signatures, and new keys can use Ed25519. The developers most likely to notice the transition are those maintaining older build infrastructure or software that has not kept pace with the SSH ecosystem.