GitHub SSH changes: new RSA keys now need at least 3,072 bits

Since 14 October, GitHub has accepted new RSA keys for authentication and signing only when they are at least 3,072 bits long. On the same date, it enabled a new hybrid key-exchange method, mlkem768x25519-sha256, combining a post-quantum mechanism with X25519 for SSH connections.

This is the first part of a broader change. GitHub scheduled temporary brownouts of the legacy RSA-with-SHA-1 signature and diffie-hellman-group-exchange-sha256 key exchange for 4 November and 9 December 2026. Both are due to be removed permanently on 13 January 2027.

The scope and dates come from GitHub’s official announcement.

Breachroad’s conclusion: most users do not need to generate a new key. The largest operational risk sits in old SSH clients embedded in CI/CD servers, build tools, integrations and appliances that have not been updated for years.

Who is affected

GitHub identifies two groups:

• people and automation using Git over SSH;
• users of the unauthenticated Git protocol on GitHub Enterprise Server.

If a Git remote starts with https://, this particular SSH change does not affect it. That does not prove the whole organisation uses HTTPS. A developer’s laptop may work while a nightly build, deployment server or old integration still connects over SSH.

The changes also apply to GitHub Enterprise Server. GitHub lists version 3.25 for the removals and new requirements, while mlkem768x25519-sha256 support arrives in version 3.24.

An existing RSA key is not automatically obsolete

The easiest misreading is that every existing RSA key must immediately be replaced with a 3,072-bit key. The length requirement applies to new keys uploaded after 14 October.

An existing RSA key can continue to work when its client uses an RSA-with-SHA-2 signature: rsa-sha2-256 or rsa-sha2-512. All RSA keys can sign with those algorithms. The problem is software capable of negotiating only the older ssh-rsa signature based on SHA-1.

The terminology is confusing. ssh-rsa can describe the generic key type visible in a public-key file, while in negotiation it also names the RSA-with-SHA-1 signature. Seeing that prefix in a key file does not by itself prove that a connection uses the weak signature.

Legacy software worth finding

GitHub provides minimum versions with robust default RSA-with-SHA-2 support:

Software	Minimum version listed by GitHub
OpenSSH	7.2p1
JSch	0.1.66 from the fork referenced by GitHub
TeamCity	2021.2.3
Go SSH	0.16.0
libssh2	1.11.0
PuTTY	0.82

This is not a complete list of applications using SSH. A library may be embedded in a product whose interface never displays its name. The inventory should therefore include developer devices, runners, release systems, bots, backup jobs, deployment automation and supplier tools.

What a brownout will reveal

A brownout is a controlled temporary shutdown of the old mechanism. It is intended to expose dependencies before the final deadline. If a connection can negotiate a newer signature and stronger key exchange, the user should see no change. An old client may fail negotiation and stop fetching code.

Do not solve that failure by permanently re-enabling SHA-1 across the organisation. It may restore one job while weakening many unrelated connections. The intended fix is to update the client, library or dependent application. GitHub recommends Ed25519 for new keys where the environment supports it.

A team plan before 4 November

1. inventory repository addresses used by people and automation;
2. separate HTTPS connections from SSH;
3. identify client and library versions on runners, build servers and appliances;
4. assign an owner to every integration, especially undocumented ones;
5. update components below supported versions;
6. test fetch and push operations from each business-critical environment;
7. monitor negotiation errors during the brownout;
8. remove emergency exceptions after remediation so they do not become permanent.

Review key-generation processes too. Documentation, runner images and tool configurations should not continue generating RSA 2048 keys when GitHub no longer accepts them as new uploads.

What ML-KEM support means

GitHub describes mlkem768x25519-sha256 as a newer, performant key-exchange option designed to remain secure against quantum computers. It is hybrid: session security does not depend solely on one new primitive. A compatible client may choose it automatically, while an older client should fall back to another supported exchange.

One added algorithm does not complete an organisation’s post-quantum migration. SSH access to GitHub is only one part of a cryptographic estate that may also include certificates, VPNs, signatures, backups, libraries and hardware. It is, however, a useful trigger to build a cryptography inventory and assign ownership.

Source facts and recommendations

The dates, minimum versions, affected-user scope, RSA 3,072-bit requirement and ML-KEM support come from GitHub’s announcement. GitHub does not say that every existing RSA key is invalid or that HTTPS users must alter their configuration.

The CI/CD inventory, business-critical automation tests and exception-handling approach are Breachroad recommendations. For the broader control model, see our guides to DevSecOps and CI/CD security and post-quantum cryptography migration. Organisations that need to test trust boundaries across delivery systems can start with a web and API penetration test.