GitHub Retires SHA-1 SSH, and Old Git Clients Feel It First

What GitHub Announced on September 22

On September 22, 2026, GitHub announced a set of changes to how github.com accepts SSH connections. Two old algorithms are going away. One is RSA signatures made with SHA-1, which SSH calls the ssh-rsa signature type, and the removal includes ssh-rsa-cert-v01@openssh.com certificates signed that way. The other is the diffie-hellman-group-exchange-sha256 key exchange, which GitHub describes as slow and little used.

Two other changes come with them. New RSA keys must be at least 3072 bits, and github.com adds mlkem768x25519-sha256, a key exchange built to resist attacks by quantum computers.

HTTPS is not part of this. If your Git remotes start with https://, nothing changes for you. The change reaches only machines that talk to GitHub over SSH, which usually means deploy servers, CI agents and developer laptops with git@github.com: remotes.

The Dates to Put in the Calendar

• October 14, 2026. New RSA SSH keys must be at least 3072 bits, for authentication and for signing. The same day mlkem768x25519-sha256 is switched on for github.com and for GitHub Enterprise Cloud with data residency, except its U.S. region.
• November 4, 2026. The first brownout, in which GitHub temporarily switches off ssh-rsa signatures and diffie-hellman-group-exchange-sha256.
• December 9, 2026. A second brownout.
• January 13, 2027. Final removal. GitHub's post prints the year as 2026, which would put the removal eight months before the announcement, so plan for January 2027.

GitHub Enterprise Server gets the removals and the 3072-bit rule in version 3.25, and the new key exchange one version earlier, in 3.24.

The brownouts are the useful part. A deploy or CI job that fails to reach GitHub over SSH on November 4 or December 9 is pointing at the machine you need to fix, with weeks still left before the removal is permanent.

Your RSA Key Is Probably Fine

The naming causes most of the confusion. ssh-rsa is the name of the RSA key type, and by an unlucky choice it is also the name of one signature algorithm, RSA with SHA-1. GitHub is retiring only that signature algorithm. Any RSA key can sign with SHA-256 or SHA-512, known as rsa-sha2-256 and rsa-sha2-512, so an existing key keeps working as long as the software using it can do that. You do not need to generate a new key for this.

OpenSSH has been able to sign with SHA-2 since version 7.2, released in February 2016. Since version 8.8, from September 2021, it refuses SHA-1 RSA signatures by default, and its release notes said at the time that most users would not notice. A machine with a current OpenSSH has been working the way GitHub now requires for years.

The 3072-bit rule applies to keys uploaded after October 14, and GitHub's post says nothing about removing smaller keys that are already registered. ssh-keygen has created 3072-bit RSA keys by default since OpenSSH 8.0 in 2019, so the rule mainly catches older tools and automation that still produce 2048-bit keys, either with an explicit -b 2048 or through a default setting. Terraform's tls_private_key resource is an example, because its rsa_bits defaults to 2048. To see the size of a key you already have:

ssh-keygen -lf ~/.ssh/id_rsa.pub

The first number in the output is the size in bits.

Where Old SSH Code Still Hides

Plain git on a Linux server hands SSH to the system's OpenSSH, so on those hosts ssh -V answers the question. The harder cases are tools that carry their own SSH implementation. GitHub lists the minimum versions that handle RSA with SHA-2 in their default configuration:

JSch is used by a lot of Java software, Go's SSH package by many single-binary tools, and libssh2 can sit inside curl, libgit2 builds and the PHP ssh2 extension. When we covered a libssh2 client bug in July, we went through the places where independent copies of that library hide, and the same inventory applies here. An operating system update does not touch a copy that an application bundled for itself.

Windows machines deserve a look as well where Git is set up to use PuTTY's plink, because PuTTY only meets GitHub's bar from version 0.82.

How to Check Before November 4

1. See who uses SSH at all. Run git remote -v in each deployed checkout. Remotes that start with https:// are out of scope.
2. Check OpenSSH where it is used. ssh -V prints the version, and anything from 7.2p1 up is fine.
3. Check the tools with their own SSH code against the table above, starting with CI servers and anything that pulls over SSH without calling the ssh binary.
4. Replace what you cannot upgrade. For older software that cannot be updated, GitHub suggests trying an Ed25519 or ECDSA key instead, and says those keys will keep working for the indefinite future. For new keys it recommends Ed25519 wherever possible, and RSA only at 3072 bits or more.

The Part That Needs No Work

The new key exchange asks nothing of you. Clients that prefer mlkem768x25519-sha256 will pick it up on their own, and older clients fall back to what they use today. OpenSSH added it in version 9.9 and made it the default for key agreement in 10.0, released in April 2025, noting that NIST has standardised the algorithm.

GitHub already offers a post-quantum hybrid today. When we connected on September 28 from OpenSSH 10.3, the session used sntrup761x25519-sha512. You can see what your own client negotiates with:

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

After October 14 an OpenSSH 10 client should show mlkem768x25519-sha256 on that line instead.

If your deploys and pipelines pull code over SSH from machines nobody has looked at in a while, the next five weeks are a good time to list them. Keeping that list current, together with the keys and runners behind it, is part of how we run CI/CD Pipeline Setup.

Sources

• GitHub Changelog: Security improvements for SSH
• OpenSSH 7.2 release notes
• OpenSSH 8.0 release notes
• OpenSSH 8.8 release notes
• OpenSSH 10.0 release notes
• Terraform TLS provider: tls_private_key