GitHub is retiring a signature type, not your key

Open a terminal in any folder that holds one of your company's repositories and run git remote -v. If every line that comes back starts with https://, you can stop reading. Nothing GitHub announced last Tuesday touches you, and the rest of this article is about somebody else's problem.

That is not me being breezy about it. It is GitHub's own sentence, in the changelog: "If your Git remotes start with https://, nothing here will affect you." They wrote almost exactly the same sentence five years ago, when they did the first half of this, and it was true then too.

What GitHub announced on 22 September is a set of SSH changes with dates attached. They are removing the ssh-rsa signature type, which means RSA keys signing with SHA-1. They are removing a key exchange mechanism called diffie-hellman-group-exchange-sha256. Any new RSA key uploaded after 14 October has to be at least 3072 bits. And they are adding a post-quantum key exchange method, mlkem768x25519-sha256, which requires nothing from anyone.

The schedule is 14 October for the key size rule, brownouts on 4 November and 9 December, and permanent removal on 13 January. GitHub's post prints that last date as "January 13, 2026," which given the three dates in front of it is plainly a typo for 2027. On GitHub Enterprise Server all of this lands in version 3.25, except the post-quantum addition, which lands in 3.24.

None of that is the interesting part. The interesting part is what people are going to do about it.

The word doing the damage is "key"

Read that list quickly and the obvious action is to generate new keys. It is the wrong action, and GitHub says so in the same post, in a sentence that is easy to miss: "You do not need to generate a new key, since all RSA keys are capable of signing with all hash algorithms."

The confusion is real and GitHub calls it out themselves. There is a key type called ssh-rsa, which is every RSA key that exists. There is also a signature type called ssh-rsa, which means an RSA key being used with SHA-1. GitHub's own words for the second one are "the confusingly named signature type ssh-rsa." Same string, two different things. The one being retired is the signature. Your key is not affected by its own name.

So nobody has to rotate anything for this. What has to change is the software doing the signing, because the choice between SHA-1 and SHA-2 is made by the SSH client at connection time, not baked into the key file. An RSA key generated in 2017 will happily sign with SHA-512 if the program holding it knows how to ask. That is the whole story: this is a software inventory problem wearing a key rotation costume.

The exposed set is smaller than it looks, and you can date it

Here is the part that turns this from a vague worry into a short list.

GitHub did the first half of this work in 2021. The post announcing it set a cutoff of 2 November 2021: from then on, newly uploaded RSA keys had to use SHA-2 signatures. Keys already on the account were explicitly grandfathered, in GitHub's phrasing, allowed to "continue to use SHA-1 signatures for the time being." The changes became permanent on 15 March 2022.

January is when "for the time being" ends.

Which means the population that breaks is: an RSA key uploaded to GitHub before 2 November 2021, being used by a client too old to sign with SHA-2, still in service today. Anything added since November 2021 has been forced onto SHA-2 for four and a half years already. If it has worked since then, it keeps working.

That is a genuinely narrow target, and it is the only place worth spending an afternoon. It is also, unhelpfully, exactly the kind of thing nobody remembers setting up.

Translate the version numbers into years

GitHub's post lists the minimum client versions that handle RSA with SHA-2 properly on default settings. The numbers on their own tell you nothing. The dates behind them tell you a lot.

| Software | GitHub's minimum | What that version is | | -------- | ------------------ | -------------------------------------------------------------------------------------------- | | OpenSSH | 7.2p1 | Released 29 February 2016 | | PuTTY | 0.82 | Released 27 November 2024 | | JSch | 0.1.66 from a fork | A version the original project never shipped | | libssh2 | 1.11.0 | The library behind many Git GUIs and appliances | | Go SSH | 0.16.0 | Used by a lot of modern CI and infrastructure tooling | | TeamCity | 2021.2.3 | The CI server, if you run it yourself |

Two rows on that table matter more than the rest.

OpenSSH is a non-issue. On macOS and Linux the standard Git client uses the operating system's SSH, and the floor is a release from February 2016. If the machine has had an OS upgrade in the last decade it is over the line by years. Current OpenSSH is 10.5p1, from August this year. You can confirm any given box with ssh -V.

PuTTY is where to look, and the version number tells you why. PuTTY added support for RSA with SHA-2 back in 0.75, in May 2021, so plenty of older installs technically do it. GitHub still names 0.82 as the minimum, and PuTTY's changelog says what changed in that release: "SHA-2 based RSA signatures are now sent with correct zero padding." A padding bug in signature generation does not fail cleanly. It fails on the subset of signatures that happen to have a leading zero byte, which is to say intermittently, and an intermittent failure gets restarted rather than diagnosed. That reading is mine rather than GitHub's, but the version they chose is the version where the bug was fixed, and PuTTY 0.82 shipped in November 2024. A Windows machine configured before then is below the line.

JSch deserves a flag of its own, because GitHub's table asks for version 0.1.66 "from this fork," and that is not a formatting quirk. The original JSch's own changelog was last modified in November 2018 and its final entry covers 0.1.55. There is no 0.1.66 from the original project and there never will be. If a Java application in your business talks to GitHub over SSH, the fix is not an upgrade, it is a dependency swap onto a community fork, and that is a developer ticket rather than an afternoon of admin work. Worth knowing in September rather than in January.

Where this actually lives in a small company

The failure mode here is not a person at a laptop. A person at a laptop notices, complains, and gets it fixed the same morning. The things that break quietly are the ones with nobody watching. Illustrative candidates rather than an inventory of yours:

• A build or deploy server somebody stood up years ago, still pulling from a repository with a deploy key that predates the 2021 cutoff.
• A Windows machine running a scheduled job through PuTTY or Plink, last touched when it was set up.
• A NAS or backup appliance with a Git sync feature, using whatever SSH library the vendor shipped in that firmware.
• A self-hosted tool that clones from GitHub on startup inside a container image nobody has rebuilt.
• An old CI server on a version predating GitHub's minimum, which is only a problem if you never upgrade it, which is the normal state of a CI server that works.

I have no way of knowing which of these you have, and the honest answer for a lot of readers is none. But the pattern across all five is the same: the exposure sits on machines whose whole value proposition is that nobody has to think about them.

The 3072-bit rule is mostly a non-event

The 14 October date reads like the scary one and is the mildest thing in the announcement. It applies to new RSA keys uploaded after that date. GitHub does not say existing 2048-bit keys stop working, and nothing in the post suggests they do.

It is also a floor the tooling cleared seven years ago. OpenSSH raised its default RSA key size to 3072 bits in version 8.0, released April 2019, citing the same NIST guidance on 128-bit equivalent security that GitHub cites now. So ssh-keygen -t rsa with no size flag has produced a compliant key on any reasonably current system since 2019.

The two ways to trip over it are mundane: an internal runbook or setup script that says -b 2048 explicitly, and an appliance or admin UI whose "generate SSH key" button produces 2048 bits with no option to change it. The first is a one-line edit. The second is a call to a vendor, and the answer may be to generate the key elsewhere and paste it in. GitHub's own recommendation for new keys is Ed25519, and they say Ed25519 and ECDSA keys "will continue to work for the indefinite future."

Use the brownouts, because they are free

The 4 November and 9 December brownouts are the most useful thing GitHub is offering here, and the easiest to ignore.

A brownout is GitHub turning the old algorithms off temporarily so that anything still depending on them fails while somebody is available to notice. It is a fire drill with a published date. That is a much better way to find the forgotten deploy server than reading an inventory, because the machine you forgot about is by definition not on the inventory.

The practical version of that is unglamorous. Put both dates in a calendar. Make sure whatever alerts you when a build fails is actually going to a person that week and not to a channel nobody reads. Then let things break on purpose, twice, with five weeks of slack after the second one. GitHub used exactly this pattern in 2021 and 2022, two brownouts and then a permanent change, so the sequence is not an experiment.

If you would rather go looking instead of waiting, the checks GitHub points at in its 2021 post are git remote -v on each repository to see whether the remote is SSH or HTTPS, ssh -V for the OpenSSH version, and ssh -vvv git@github.com for verbose output showing what your client and GitHub actually negotiate. I have not run these against a machine in the at-risk population, so treat them as GitHub's documented diagnostics rather than a tested walkthrough.

The post-quantum addition asks nothing of you

mlkem768x25519-sha256 arrives on 14 October for github.com and GitHub Enterprise Cloud with Data Residency, except the U.S. region, and GitHub does not explain the carve-out. Clients that support it will choose it automatically; clients that do not will fall back. There is no action here, which is the nicest kind of announcement.

It is worth understanding why it is in the same post, though. The reasoning GitHub gives for removing the old Diffie-Hellman method is that it is "slow, little-used" and "could be broken with advances in quantum computing." Recorded traffic can be decrypted later by whoever holds the recording when the maths gets cheaper. That argument applies to a key exchange, which protects the session, and it does not apply to the SHA-1 signature removal, which is about a hash that is already broken today for reasons that have nothing to do with quantum computers. Two different problems in one post, and the easy mistake is to read the January deadline as a quantum precaution when it is housekeeping on a hash that cryptographers stopped trusting long before anybody was selling quantum risk.

What to do with this

If all your remotes are HTTPS, nothing. That was the first paragraph and it is still the answer.

If you use SSH, the pass to make is a list rather than a key rotation: every machine in the business that pushes to or pulls from GitHub without a person sitting in front of it. For each one, what software makes the connection and what version is it. Most will be OpenSSH and fine. The candidates for real work are Windows machines on PuTTY older than November 2024, Java applications on stock JSch, and anything running a Git client shipped inside firmware.

What not to do is generate a fleet of new keys, chase everyone in the company to re-upload them, and then find in January that the one machine that mattered is still broken because the problem was never the key. GitHub told you that in the announcement. It is just not the sentence that travels.