GitHub's New SSH Changes: Which Algorithms Should You Remove First?

SSH is a common way to connect Git clients, CI systems, deployment servers, and automation tools to GitHub. That also makes the SSH configuration on developer machines and build infrastructure an important part of software supply-chain security.

GitHub announced new SSH security changes on September 22, 2026. The changes remove RSA signatures that use SHA-1, remove the diffie-hellman-group-exchange-sha256 key exchange mechanism, increase the minimum size for newly uploaded RSA keys, and add support for the post-quantum mlkem768x25519-sha256 key exchange method in supported GitHub environments.

For developers, the important question is not simply "Do I use RSA?" The more useful question is:

Which SSH algorithm is my client actually using?

That distinction matters because an existing RSA key does not automatically need to be replaced.

What Is Changing in GitHub SSH?

GitHub is making four significant changes.

GitHub says these changes apply to Git clients connecting over SSH. Git remotes using https:// are not affected by these specific SSH changes.

Difference Between ssh-rsa and RSA Keys

This is where many developers can misunderstand the announcement.

An RSA key and the ssh-rsa signature algorithm are not exactly the same thing.

GitHub explains that ssh-rsa can refer to the RSA key type, while the ssh-rsa signature type specifically represents RSA signatures using SHA-1. The newer rsa-sha2-256 and rsa-sha2-512 signature types use SHA-2 instead.

RSA key
   |
   +-- rsa-sha2-256
   |
   +-- rsa-sha2-512
   |
   +-- ssh-rsa / SHA-1

does not mean every RSA key must be deleted.

If your existing RSA key is being used with RSA-SHA-2 signatures, GitHub says you can continue using it.

Which Algorithm Should You Check First?

For most teams, the first thing to investigate is:

ssh-rsa

because GitHub is removing the SHA-1-based signature type.

The second algorithm to check is:

diffie-hellman-group-exchange-sha256

because GitHub is also removing this key exchange mechanism.

You should then review the age of the SSH client or library used by your development machines, CI runners, deployment servers, and automation.

How to Check Your SSH Key Type

Start by looking at the keys on your machine.

On Linux, macOS, or Git Bash:

ls -la ~/.ssh

You may see files such as:

id_ed25519
id_ed25519.pub
id_rsa
id_rsa.pub

The filename alone does not tell you which signature algorithm will be negotiated during an SSH connection.

For an RSA public key, you can inspect the key with:

ssh-keygen -lf ~/.ssh/id_rsa.pub

This helps identify the key and its size.

For example, an RSA key might show:

4096 SHA256:xxxxxxxxxxxxxxxx [email protected] (RSA)

An RSA key being present does not by itself mean that the deprecated SHA-1 signature type is being used.

Check the Actual SSH Negotiation

For troubleshooting, SSH's verbose output is more useful.

Run:

ssh -vT [email protected]

For more detailed output:

ssh -vvT [email protected]

Look through the output for authentication and key-exchange information.

You are interested in whether the client is negotiating modern algorithms such as:

rsa-sha2-256
rsa-sha2-512
ssh-ed25519

and whether it is attempting to rely on:

ssh-rsa
diffie-hellman-group-exchange-sha256

The exact output depends on the SSH implementation and configuration.

Check Your OpenSSH Version

Older SSH clients are more likely to create compatibility problems.

Check your version with:

ssh -V

GitHub lists OpenSSH 7.2p1 as the minimum version in its published table for robust RSA-SHA-2 support with the default configuration. It also lists minimum versions for several other commonly used SSH implementations.

If your CI system uses an embedded SSH library rather than the operating system's OpenSSH installation, check the library version separately.

What About Existing RSA Keys?

This is one of the most useful parts of the announcement.

You do not automatically need to regenerate every existing RSA key.

GitHub states that existing RSA keys can continue to work when the SSH implementation uses:

rsa-sha2-256

or:

rsa-sha2-512

GitHub also notes that RSA keys are capable of signing with different supported hash algorithms.

So before replacing a working key:

Existing RSA key
      |
      v
Check SSH client
      |
      v
Supports RSA-SHA-2?
      |
   +--+--+
   |     |
  Yes    No
   |     |
Keep   Upgrade
key    client

This can avoid unnecessary credential rotation.

What Should You Use for New SSH Keys?

For new keys, GitHub recommends Ed25519 when possible. It also states that Ed25519 and ECDSA keys it supports will continue to work with these changes.

A new Ed25519 key can be generated with:

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

If another system requires RSA, GitHub says new RSA keys can still be generated, provided they are at least 3072 bits.

For example:

ssh-keygen -t rsa -b 3072 -C "[email protected]"

For a new key, the decision should also consider compatibility with other systems that use the same credential.

What Is Happening to diffie-hellman-group-exchange-sha256?

The key-exchange side of the change is separate from the RSA signature change.

GitHub is removing:

diffie-hellman-group-exchange-sha256

GitHub describes it as an older Diffie-Hellman mechanism and says SSH implementations that support RSA-SHA-2 should also support a stronger key-exchange mechanism.

This is primarily a client compatibility issue.

If your SSH client is sufficiently modern, you generally should not need to manually configure a replacement algorithm. The better approach is to update the SSH implementation rather than adding a legacy compatibility setting.

What Is the New Post-Quantum Algorithm?

GitHub is also adding:

mlkem768x25519-sha256

for SSH sessions on GitHub.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region. GitHub describes ML-KEM as a post-quantum key-exchange method.

For most developers, this does not require manually changing an SSH configuration.

GitHub says compatible SSH clients can automatically use the newer algorithm when configured to prefer it, while older clients can fall back to another supported key-exchange algorithm.

Pay Attention to the October 14 Requirement

There is one date developers should put on their migration checklist.

Starting October 14, 2026, newly uploaded RSA SSH keys must be at least 3072 bits for both signing and authentication.

This does not mean that every existing smaller RSA key immediately stops working.

It means that when you upload a new RSA key after that date, it must meet the new minimum.

For teams that automatically generate deploy keys or credentials, this should be checked in the provisioning process.

GitHub's Brownout Schedule

GitHub has announced temporary brownouts before the final removal of the affected algorithms:

• November 4, 2026 - first brownout

• December 9, 2026 - second brownout

• GitHub's announcement lists January 13, 2026 as the removal date, but that date conflicts with the announcement's later 2026 brownouts and October 2026 changes. The published date therefore appears chronologically inconsistent and should be verified against GitHub's notice before being used for a production migration deadline.

The brownouts are particularly useful for teams because they can expose old clients before the permanent removal.

Check CI and Automation, Not Just Developer Machines

A common mistake is checking only:

Developer Laptop

while forgetting:

CI Runner
Deployment Server
Build Server
Release Automation
Container Image
Self-Hosted Runner
Git Library

A developer's workstation may already use a modern OpenSSH version while an old CI container still contains an outdated SSH library.

For example:

Developer
   |
   +--> OpenSSH 9.x       OK

CI Runner
   |
   +--> Old SSH Library   Check

Deployment Server
   |
   +--> Legacy Client     Check

The older environment may be the one that fails when GitHub removes the legacy algorithm.

Check Git Remotes

You can identify whether a repository uses SSH with:

git remote -v

An SSH remote commonly looks like:

[email protected]:organization/project.git

An HTTPS remote looks like:

https://github.com/organization/project.git

GitHub states that these specific SSH changes do not affect Git remotes that use HTTPS.

This gives teams a simple first-level inventory:

Git Remote
    |
    +--> HTTPS
    |      |
    |      +--> Not affected by these SSH changes
    |
    +--> SSH
           |
           +--> Inspect client and algorithms

Common Mistakes to Avoid

Replacing Every RSA Key

An RSA key is not automatically a problem. Check whether the client is using RSA-SHA-2 first.

Looking Only at Key Files

id_rsa does not tell you which signature algorithm is actually negotiated.

Ignoring CI

Old automation environments are easy to overlook.

Adding Legacy Algorithms to Fix an Error

A compatibility workaround that explicitly enables an old algorithm may only postpone the problem.

Updating the Key but Not the SSH Library

Generating a modern key does not fix a client that cannot negotiate the required SSH algorithms.

Forgetting Embedded Libraries

Applications using JSch, Go SSH, libssh2, or other SSH libraries need their own compatibility review.

A Practical Migration Checklist

Use this checklist before the changes take effect:

1. Find repositories and automation that use Git over SSH.

2. Check SSH client versions on developer machines and servers.

3. Check SSH libraries used by CI and deployment tools.

4. Identify RSA keys and their sizes.

5. Confirm existing RSA keys use RSA-SHA-2 signatures.

6. Check for configurations explicitly enabling ssh-rsa.

7. Check for use of diffie-hellman-group-exchange-sha256.

8. Upgrade old SSH clients and libraries.

9. Prefer Ed25519 for newly generated keys when compatibility allows.

10. Ensure new RSA keys are at least 3072 bits.

11. Test during GitHub's brownout periods.

12. Monitor CI and deployment failures after the changes.

Advantages of the Changes

The SSH changes provide several security improvements:

• Removal of RSA SHA-1 signatures

• Removal of an older Diffie-Hellman key-exchange mechanism

• Stronger requirements for newly uploaded RSA keys

• Availability of a post-quantum key-exchange option

• An opportunity to identify outdated SSH clients and libraries

These changes also encourage teams to treat SSH clients and libraries as part of their software supply chain rather than as infrastructure that can be ignored after initial configuration.

What Developers Should Do First

The migration does not need to start with replacing every SSH credential.

A more useful order is:

1. Inventory SSH usage
        |
        v
2. Identify old clients/libraries
        |
        v
3. Check actual algorithms
        |
        v
4. Upgrade incompatible software
        |
        v
5. Generate new keys only when needed
        |
        v
6. Test CI and deployments
        |
        v
7. Monitor brownouts

This approach separates algorithm compatibility from key rotation.

That distinction is important because an existing RSA key can remain useful when the SSH implementation supports RSA-SHA-2.

Summary of the Article

GitHub's upcoming SSH changes are primarily about removing older cryptographic mechanisms and raising the security baseline for SSH connections.

The two algorithms developers should investigate first are:

ssh-rsa
diffie-hellman-group-exchange-sha256

The first refers specifically to RSA signatures using SHA-1 in this context. The second is an older key-exchange mechanism that GitHub is removing. GitHub is also requiring new RSA SSH keys uploaded after October 14, 2026 to be at least 3072 bits and is adding support for the post-quantum mlkem768x25519-sha256 key exchange in supported environments.

The most important practical point is that developers should not assume every RSA key must be replaced. Existing RSA keys can continue to work when the SSH client uses rsa-sha2-256 or rsa-sha2-512.

Teams should inventory SSH usage across developer machines, CI runners, deployment systems, and embedded SSH libraries, upgrade outdated clients, prefer Ed25519 for new keys where practical, and use the announced brownouts to find compatibility problems before the legacy algorithms are removed.