GitHub SSH RSA: 3072-bit keys from 14 October, SHA-1 out

The GitHub SSH RSA rules change on 14 October 2026: every new RSA key uploaded after that date must be at least 3072 bits. The bigger break comes later, when GitHub removes the ssh-rsa SHA-1 signature type and the diffie-hellman-group-exchange-sha256 key exchange, after brownouts on 4 November and 9 December 2026. If your remotes start with https://, none of this touches you.

Date	What happens
14 October 2026	New RSA keys must be 3072 bits or larger. mlkem768x25519-sha256 enabled on github.com and GitHub Enterprise Cloud with Data Residency, except the U.S. region.
4 November 2026	First brownout of ssh-rsa and diffie-hellman-group-exchange-sha256.
9 December 2026	Second brownout of the same two algorithms.
13 January (see below)	Permanent removal of both.

The removal date on GitHub's own changelog cannot be right

Read the schedule literally and the last step happens before the first. GitHub's changelog says, verbatim:

January 13, 2026: We'll remove the ssh-rsa signature type and diffie-hellman-group-exchange-sha256 key exchange algorithm.

January 2026 is nine months before the 14 October 2026 start date and two months before the changelog was published on 22 September 2026. Every other dated step in the post — 14 October, 4 November, 9 December — falls on a Wednesday in 2026; 13 January 2026 was a Tuesday, and 13 January 2027 is a Wednesday. The obvious reading is that removal lands on 13 January 2027, but the page has not been corrected as of 23 September 2026, so plan against that date and re-check the changelog before you commit to it in a maintenance window.

The practical consequence is small, because the brownouts are the real deadline. If your connection survives 4 November and 9 December, the removal date is a formality. If it does not, you have five weeks between the two to fix it.

How to check whether your GitHub SSH RSA key is affected

Two separate questions hide behind one name, and GitHub's changelog is explicit about the confusion: the key type ssh-rsa applies to every RSA key regardless of signature algorithm, while the signature type ssh-rsa means an RSA key signing with SHA-1. It is the signature type that is going.

1. List your keys. GitHub documents ls -al ~/.ssh; the supported public key filenames are id_rsa.pub, id_ecdsa.pub and id_ed25519.pub. No RSA key, no problem on the signature side.
2. Check the size. Run ssh-keygen -lf ~/.ssh/id_rsa.pub. The first field is the key length in bits. A 2048-bit key still works after 14 October — the minimum applies to new keys uploaded after that date, not to keys already on your account.
3. Check what your client negotiates. Run ssh -vT git@github.com and read the verbose output for the key exchange and signature algorithms actually chosen. That, not the key file, is what breaks during a brownout.

The reason the third step matters more than the second: GitHub's position is that you do not need to generate a new key at all. All RSA keys can sign with any hash algorithm, so a client that supports rsa-sha2-256 or rsa-sha2-512 will pick one automatically and keep working with the key you already have. The failure mode is an old client, not an old key.

The client versions that decide this

GitHub publishes the minimum versions that support RSA with SHA-2 robustly in the default configuration. This is the table to check your build images against:

Software	Minimum version
OpenSSH	7.2p1
JSch	0.1.66 (from the fork GitHub links)
TeamCity	2021.2.3
Go SSH	0.16.0
libssh2	1.11.0
PuTTY	0.82

OpenSSH 7.2p1 is from 2016, so a current developer laptop is fine. The risk sits in the places nobody upgrades: a pinned CI image, a build agent on an old LTS, a Jenkins controller using JSch, a Go service that clones repositories with an old x/crypto/ssh, a deployment script on a jump host. In the systems we work on, those are exactly the hosts with no owner and no upgrade path, and they fail on a Wednesday in November rather than when someone is watching.

What to do in CI before 4 November

Treat the first brownout as the deadline and use it as a free test. The work is small and it is the same in every pipeline we have had to fix.

• Inventory which jobs clone over SSH. Anything using an HTTPS remote with a token is out of scope entirely.
• Print ssh -V in the job and compare against 7.2p1. Do it now rather than reading the Dockerfile — base images drift.
• Deploy keys and machine users have their own key material, often generated years ago by someone who has left. They are the ones to look at first.
• Swap deploy keys to Ed25519 rather than auditing each one. A CI/CD pipeline that regenerates a key is cheaper than one that proves an old key is safe.
• Watch the 4 November and 9 December windows. A brownout is a rehearsal with the failure already scheduled, which is more than most deprecations give you — unlike, say, the Copilot model removals on 19 October, which simply take effect.

Generate Ed25519, and what the post-quantum addition changes

For anything new, GitHub's recommendation is unambiguous: use Ed25519 whenever possible. The documented command is ssh-keygen -t ed25519 -C "your_email@example.com", with ssh-keygen -t rsa -b 4096 offered only for legacy systems that cannot do Ed25519 — comfortably above the new 3072-bit floor. Ed25519 and ECDSA keys, GitHub says, will continue to work for the indefinite future.

The post-quantum half of the announcement needs nothing from you. mlkem768x25519-sha256 becomes available on 14 October for key exchange; clients that prefer it use it automatically, and older clients fall back. It is the first time most teams will have a post-quantum algorithm in a production path without configuring anything, which is worth noting in your risk register even though it requires no work. On GitHub Enterprise Server, all of these changes arrive in version 3.25 except the ML-KEM addition, which lands in 3.24.

One correction to a common assumption: this is not a key rotation exercise for most people. It is a client inventory. The keys on your account are almost certainly fine; the SSH implementations reaching GitHub from your build fleet are the open question, and you have until 4 November to find out which of them cannot answer it. If your build estate is old enough that nobody knows what is in the images, that audit is the kind of work our DevOps and cloud engineering team does before the deadline rather than during the incident.