Skip to content
chornous.dev

Type two or more letters. Esc closes.

Index of sheets
Theme

Sheet 03 · Writing

All notes

GitHub drops SHA-1 RSA signatures over SSH and adds a post-quantum key exchange

GitHub's September 22, 2026 changelog removes the ssh-rsa signature type and diffie-hellman-group-exchange-sha256, requires 3072-bit RSA keys from October 14, and turns on mlkem768x25519-sha256. Brownouts land on November 4 and December 9.

Pl. 15 · section drawing generated from the slug “github-ssh-rsa-sha1-removal”

GitHub published a changelog entry on September 22, 2026 that changes which SSH algorithms github.com accepts. It removes RSA signatures that use SHA-1, retires a Diffie-Hellman key exchange, sets a 3072-bit floor for new RSA keys and adds a post-quantum key exchange. If your Git remotes start with https://, none of this touches you. If they start with [email protected]:, check your clients before November 4.

The four changes

From GitHub's "Security improvements for SSH" changelog
ChangeScopeWhen
Remove the ssh-rsa signature type (RSA with SHA-1), SHA-1 certificates includedGit over SSHbrownouts Nov 4 and Dec 9, then removal
Remove diffie-hellman-group-exchange-sha256Git over SSHsame schedule
New RSA keys must be at least 3072 bits, for signing and authenticationkeys uploaded after Oct 14Oct 14, 2026
Add mlkem768x25519-sha256github.com and Data Residency, U.S. region excludedOct 14, 2026

GitHub Enterprise Server picks up the removals in 3.25 and the ML-KEM exchange in 3.24.

The entry lists the final removal as "January 13, 2026", a date eight months before the announcement. The December 9 brownout comes first, so plan for January 13, 2027 and watch the changelog for a correction.

Key type and signature type share a name

GitHub calls out the naming clash itself. ssh-rsa is the key type of any RSA key. ssh-rsa is also the name of a signature algorithm, RSA over SHA-1, and that algorithm is the one leaving. Your existing RSA key can sign with rsa-sha2-256 or rsa-sha2-512 instead, so you keep the key as long as your SSH client speaks SHA-2. Most clients that support SHA-2 pick it on their own.

You can see what your client negotiates with GitHub from a verbose connection:

# which key exchange and signature algorithms the session used
ssh -vT [email protected] 2>&1 | grep -E "kex: algorithm|server-sig-algs|Server accepts key"

# does this client know the new post-quantum exchange?
ssh -Q kex | grep mlkem

# how many bits does your RSA key have?
ssh-keygen -lf ~/.ssh/id_rsa.pub

Run the first command on each build agent and runner image you own, as well as on your laptop. A current laptop passes. Old SSH libraries tend to hide in agents you haven't rebuilt in years.

Minimum client versions

GitHub lists the versions that support RSA with SHA-2 in their default configuration:

Minimum versions from the changelog
SoftwareMinimum version
OpenSSH7.2p1
JSch0.1.66, from a maintained fork
TeamCity2021.2.3
Go SSH0.16.0
libssh21.11.0
PuTTY0.82

The JSch row points at a fork, so a Java tool that bundles the original library needs a closer look. Check any Go service that clones repositories with a pinned SSH library too, and PuTTY on shared Windows machines.

If you can't upgrade a client, GitHub says Ed25519 and ECDSA keys "will continue to work for the indefinite future." Switching the key type sidesteps the SHA-1 question.

New keys

GitHub recommends Ed25519 for new keys. Keep RSA for services that can't read anything else, and give it at least 3072 bits:

# preferred
ssh-keygen -t ed25519 -C "[email protected]"

# when a service still insists on RSA
ssh-keygen -t rsa -b 4096 -C "[email protected]"

The 3072-bit floor applies to RSA keys uploaded after October 14. The changelog says nothing about rejecting 2048-bit keys already on your account. Any script that generates and uploads a fresh key with -b 2048, for a deploy key or a bot account, will hit the new floor, so grep your infrastructure repos for that flag.

The post-quantum exchange

The mlkem768x25519-sha256 method combines ML-KEM with X25519. You don't configure anything: clients that prefer it will use it, and older clients fall back to an existing exchange. The removed diffie-hellman-group-exchange-sha256 is, in GitHub's description, slow and little used, so a client that supports SHA-2 signatures will have a stronger exchange available.

Data Residency customers in the U.S. region won't get ML-KEM on October 14. The entry gives no date for them.

This week

  1. Oct 14, 2026

    3072-bit floor for new RSA keys. ML-KEM turns on.
  2. Nov 4, 2026

    First brownout of ssh-rsa signatures and the old Diffie-Hellman exchange.
  3. Dec 9, 2026

    Second brownout.
  4. Jan 13

    Removal. The changelog prints 2026.
  1. Run git remote -v in the repositories your CI touches and list the ones on SSH.
  2. Run ssh -vT [email protected] from each runner image and build agent. Anything that negotiates SHA-1 needs an upgrade or an Ed25519 key.
  3. Grep provisioning scripts for ssh-keygen -t rsa -b 2048 and raise the size.
  4. Put November 4 in the on-call calendar. A clone that fails that day is the brownout doing its job, and you get a month to fix it before the removal.

Volodymyr Chornous