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 2026 — removal.

That last date, as printed in GitHub's own schedule, is in the past: January 2026 came and went eight months before the announcement. The only reading consistent with brownouts in November and December 2026 is 13 January 2027, and that is what we would plan against — but GitHub has not corrected the entry, and we are not going to pretend a typo is a commitment. Treat 9 December as the date by which everything must already work, which is the sensible plan regardless of what the final line says.

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, including the schedule and the printed removal date of 13 January 2026 that cannot be correct. No independent report of it was found, so every date here comes from the vendor's own page and is only as reliable as that page. We will update this when it can be confirmed, and remove this note.

Sources

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