Security improvements for SSH

We’re removing several SSH algorithms, adding a new algorithm, and requiring larger RSA SSH keys to improve security.

The changes are as follows:

• We’re removing the ability to use RSA keys using SHA-1 in SSH (i.e., the ssh-rsa signature type, including ssh-rsa-cert-v01@openssh.com certificates using SHA-1).
• We’re removing the key exchange mechanism diffie-hellman-group-exchange-sha256.
• All new RSA SSH keys uploaded after October 14, 2026 must be at least 3072 bits in size, both for signing and authentication.
• We’re additionally supporting the post-quantum key exchange method mlkem768x25519-sha256 for SSH sessions on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region.

Adding ML-KEM lets us offer a newer, more performant key exchange method that is secure against quantum computers.

We’re also removing the older Diffie-Hellman method, a slow, little-used algorithm that could be broken with advances in quantum computing. For RSA, we’re removing the use of SHA-1 since it’s known to be weak, as well as increasing key sizes to align with 128-bit security requirements.

Schedule

• October 14, 2026: The new RSA key size requirements take effect. In addition, mlkem768x25519-sha256 will be enabled on github.com and GitHub Enterprise Cloud with Data Residency (except for the U.S. region).
• November 4, 2026: We’ll have a brownout of the removal of the ssh-rsa signature type (i.e., RSA keys using SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange algorithm.
• December 9, 2026: We’ll have another brownout for the ssh-rsa signature type and the diffie-hellman-group-exchange-sha256 key exchange algorithm.
• January 13, 2026: We’ll remove the ssh-rsa signature type and diffie-hellman-group-exchange-sha256 key exchange algorithm.

These changes will all take effect in GitHub Enterprise Server in version 3.25, except for the addition of mlkem768x25519-sha256, which will take effect in version 3.24.

Preparing for these changes

The only affected users are those connecting with a Git client over SSH or those using the unauthenticated Git protocol on GitHub Enterprise Server. If your Git remotes start with https://, nothing here will affect you.

RSA key changes

If you’re using an existing RSA key, make sure you’re using RSA with SHA-2 (i.e., the rsa-sha2-256 and rsa-sha2-512 signature types). You do not need to generate a new key, since all RSA keys are capable of signing with all hash algorithms. As long as the SSH program or library you’re using supports RSA with SHA-2, you can continue to use the same key without a problem and most SSH implementations supporting RSA with SHA-2 will choose it automatically.

Note the distinction between the key type ssh-rsa, which applies generically to all RSA keys regardless of signature algorithm, and the confusingly named signature type ssh-rsa, which indicates an RSA key using SHA-1 (as opposed to rsa-sha2-256 and rsa-sha2-512, which refer to RSA keys using SHA-256 and SHA-512, respectively).

Here’s a list of some common software that uses SSH to connect to GitHub and the version necessary to support RSA with SHA-2 robustly with the default configuration:

Software	Minimum Version
OpenSSH	7.2p1
JSch	0.1.66 from this fork
TeamCity	2021.2.3
Go SSH	0.16.0
libssh2	1.11.0
PuTTY	0.82

Alternatively, if you’re using older software and can’t upgrade, you may be able to use an Ed25519 or ECDSA key instead. All Ed25519 and ECDSA keys we support are strong, secure, and will continue to work for the indefinite future.

For generating new keys, we recommend using an Ed25519 key whenever possible. However, if you still need an RSA key for compatibility with other services, you can generate one as long as it as at least 3072 bits in size.

Removal of diffie-hellman-group-exchange-sha256

If you’re using one of the SSH implementations above that supports RSA with SHA-2, it should also support a strong key exchange mechanism.

New post-quantum algorithms

The addition of the mlkem768x25519-sha256 shouldn’t require any changes from users. SSH clients will automatically use the new algorithm by default if configured to prefer it. Users who use an older SSH client should automatically fall back to an older key exchange algorithm.

The post Security improvements for SSH appeared first on The GitHub Blog.