DEVELOPMENT · SSH · GITHUB

GitHub hardens SSH: do you need to change your keys before October 2026?

Starting October 14, 2026, GitHub will require newly uploaded RSA keys to be at least 3072 bits and will enable a new hybrid post-quantum key exchange. But an existing RSA key does not automatically need replacement.

GitHub is modernizing its SSH stack: phasing out RSA signatures based on SHA-1, retiring an older Diffie-Hellman exchange, increasing the minimum size for newly uploaded RSA keys, and adding ML-KEM support. For most users with current clients, the transition should be transparent.

What changes on October 14, 2026

  • New RSA keys uploaded to GitHub must be at least 3072 bits.
  • GitHub will enable mlkem768x25519-sha256, a hybrid post-quantum key exchange, on github.com and selected GitHub Enterprise Cloud offerings.
  • The legacy ssh-rsa signature using SHA-1 is being retired.
  • diffie-hellman-group-exchange-sha256 is also being phased out.

Your RSA key is not necessarily obsolete

The confusing part is the name ssh-rsa. It can refer to the RSA key type, but GitHub is targeting the legacy RSA signature using SHA-1.

An existing RSA key can continue to work if your SSH client signs with rsa-sha2-256 or rsa-sha2-512. GitHub explicitly says a new key is not required in that case.

Key point

RSA is not being removed. GitHub is primarily removing RSA+SHA-1. The new 3072-bit requirement applies to RSA keys uploaded after October 14, 2026.

Should you switch to Ed25519?

For a new key, GitHub recommends Ed25519 whenever possible. It is generally the simplest choice for a modern developer workstation.

RSA remains useful when compatibility with older tools or devices requires it. In that case, any newly uploaded key after October 14 must be at least 3072 bits.

What does ML-KEM mean for SSH?

mlkem768x25519-sha256 is a hybrid key exchange: it combines post-quantum ML-KEM with X25519, a widely deployed classical primitive.

This does not replace your personal SSH key. Key exchange establishes the session secret between your client and GitHub; your Ed25519 or RSA key still authenticates you.

If your client supports and prefers the new method, it can negotiate it automatically. Older clients will fall back to another supported exchange.

Who should check their setup?

Users whose remotes start with git@github.com: or otherwise use SSH are affected by these changes. HTTPS remotes are not.

GitHub lists OpenSSH 7.2p1+, TeamCity 2021.2.3+, Go SSH 0.16.0+, libssh2 1.11.0+ and PuTTY 0.82+ among versions with robust RSA-SHA-2 support.

Simple checks to perform

  • Check whether your remotes use SSH or HTTPS with git remote -v.
  • Check your client version with ssh -V.
  • Avoid configurations that explicitly force the legacy ssh-rsa signature.
  • For new keys, prefer Ed25519 where supported.
  • If RSA is still required, use at least 3072 bits for newly uploaded keys.
  • Test old automation, embedded SSH libraries and runners that may use their own SSH implementation.

Dates to watch

GitHub plans a first brownout of the legacy algorithms on November 4, 2026, followed by another on December 9, 2026. These temporary interruptions can reveal clients still depending on the algorithms being retired.

No panic, but a good time to audit SSH

If you use a recent OpenSSH client and Ed25519, there is probably nothing to change. For an existing RSA key, the priority is to verify that your client uses RSA-SHA-2 rather than SHA-1.

The most visible October 14 change is the stronger size requirement for newly uploaded RSA keys. ML-KEM is notable for another reason: post-quantum migration is becoming a routine protocol evolution rather than a purely theoretical topic.

Sources

Published September 23, 2026.