GitHub sets a removal date for SHA-1 RSA over SSH, with two brownouts first

GitHub sets a removal date for SHA-1 RSA over SSH, with two brownouts first

22 September 2026: GitHub published a schedule on 22 September 2026 for removing two SSH algorithms and tightening a third. It affects anyone whose remotes start with git@; anyone using HTTPS remotes can stop reading.

The schedule, and the date that cannot be right

Three things go, or change, on published dates:

• 14 October 2026: every new RSA key uploaded after this date must be at least 3,072 bits, for signing and for authentication. Existing keys are not affected by the size rule. The post-quantum key exchange mlkem768x25519-sha256 is enabled on the same day, on github.com and on GitHub Enterprise Cloud with Data Residency, except the US region.
• 4 November 2026: first brownout of the ssh-rsa signature type and the diffie-hellman-group-exchange-sha256 key exchange.
• 9 December 2026: second brownout of the same two.
• 13 January 2027: removal.

GitHub first printed the removal date as 13 January 2026, a date already in the past. Its changelog entry now reads 13 January 2027 (checked on 15 October 2026), which fits the brownouts in November and December. Treat 9 December as the last date by which every client and server key should have moved off ssh-rsa, since that brownout is the final rehearsal.

The distinction that catches people out

There are two things called ssh-rsa and only one of them is going away. The key type ssh-rsa covers every RSA key you have ever generated and is not being removed. The signature type ssh-rsa means an RSA key signing with SHA-1, and that is what stops working.

The practical consequence is that you almost certainly do not need to generate new keys. Any RSA key can sign with SHA-2; what matters is whether the client software picks rsa-sha2-256 or rsa-sha2-512, which modern implementations do automatically. GitHub lists the minimum versions: OpenSSH 7.2p1, libssh2 1.11.0, PuTTY 0.82, Go SSH 0.16.0, TeamCity 2021.2.3, and a specific fork of JSch at 0.1.66.

What to do about it

The keys on your laptop are not the risk. The risk is the SSH client nobody has touched in five years: a build agent on a pinned base image, an appliance that mirrors a repository on a schedule, a deployment script inside a container built from an old distribution, a Java service using an ancient JSch. Those are exactly the things that will fail silently on 4 November and be blamed on something else.

Inventory every non-human client that talks to GitHub over SSH, check its version against that table, and if it cannot be upgraded, replace the key with an Ed25519 one - which GitHub recommends for new keys anyway and which sidesteps the whole question. Do that before the first brownout, and use the brownout as the test rather than as the incident.

Not yet independently verified. This rests entirely on GitHub's own changelog entry. GitHub has since corrected the removal date to 13 January 2027; no independent report of the schedule was found. We will update this when it can be confirmed, and remove this note.

Sources

• GitHub Changelog: Security improvements for SSH - 22 September 2026