GitHub is tightening SSH security. The upcoming changes remove RSA signatures that use SHA-1, remove the `diffie-hellman-group-exchange-sha256` key exchange, and require new RSA SSH keys uploaded after October 14, 2026 to be at least 3072 bits. GitHub also plans to support the post-quantum key exchange `mlkem768x25519-sha256` on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region. See the official SSH security update for the complete schedule and scope.
If your Git remote starts with `https://`, this specific change does not affect it. If you use `git@github.com:...` or another SSH remote, check the client and library used by every laptop, build runner, deployment host, and automation service.
The dates to put on your calendar
• October 14, 2026: new RSA SSH keys uploaded to GitHub must be at least 3072 bits. GitHub also enables the new ML-KEM key exchange on the supported services and regions.
• November 4, 2026: first brownout for the `ssh-rsa` SHA-1 signature type and `diffie-hellman-group-exchange-sha256`.
• December 9, 2026: second brownout for the same algorithms.
• The removal follows the brownouts. Check GitHub’s current schedule before planning a final cutover.
The brownouts are useful because they expose old clients before the final removal. Test during both windows if you operate long-lived runners or have customers connecting through an embedded SSH library.
Do not confuse the two meanings of ssh-rsa
GitHub’s naming is easy to misread. `ssh-rsa` can describe an RSA key in a generic key-type context, but the `ssh-rsa` signature algorithm specifically means RSA with SHA-1. The upcoming removal targets the SHA-1 signature algorithm. An existing RSA key can keep working when the client signs with `rsa-sha2-256` or `rsa-sha2-512`.
You usually do not need to replace an existing RSA key just because it is RSA. The important question is whether the SSH program or library supports RSA with SHA-2 and chooses it. Modern implementations generally do. Ed25519 is the recommended choice for new keys when your other systems support it.
Find every SSH path
Start with the obvious Git remotes, then look for the less visible paths: submodules, deployment scripts, package managers, release tools, GitHub Actions self-hosted runners, Docker build hosts, and Java or Go services that embed an SSH library.
# List remotes in the current repository
git remote -v
# Show the SSH client version used on this machine
ssh -V
# Test GitHub authentication with verbose negotiation output
ssh -vvT git@github.com
# Inspect the effective SSH configuration for GitHub
ssh -G github.com | grep -E '^(user|hostname|port|hostkeyalgorithms|pubkeyacceptedalgorithms|kexalgorithms)'
# Inspect a public key without exposing the private key
ssh-keygen -lf ~/.ssh/id_rsa.pubRun the SSH test in the same environment that performs the real operation. A developer laptop can work while a container, deployment host, or CI runner still uses an old client. Treat a failed `ssh -T` as a clue, not proof of the exact cause: the verbose output may point to the client version, a forced algorithm in SSH config, an intermediate bastion, or the key actually offered.
Check client and library versions
GitHub lists these minimum versions for RSA SHA-2 support with default configuration: OpenSSH 7.2p1, JSch 0.1.66 from the linked fork, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0, and PuTTY 0.82. Use the versions from the official GitHub guidance as a baseline, then check your vendor’s current support policy before upgrading production systems.
The version check is especially important for embedded libraries. Updating Git on a workstation does not update JSch in a build server or libssh2 in another application. Inventory the component that actually opens the SSH connection.
Generate a new key only when you need one
If your client supports RSA SHA-2, keep the existing RSA key and test it. If the client is too old to use SHA-2 and cannot be upgraded, move the affected integration to a supported Ed25519 or ECDSA key where the surrounding system allows it. For a new RSA key, use at least 3072 bits after the October 14 requirement takes effect.
# Recommended new key for most modern clients
ssh-keygen -t ed25519 -C "ci-github-$(hostname)"
# Compatible RSA alternative
ssh-keygen -t rsa -b 3072 -C "ci-github-$(hostname)"Do not overwrite a working private key in place. Create the replacement separately, upload only its public key through the approved GitHub or machine-user process, test the new connection, and remove the old key after the dependency inventory confirms it is unused. Keep private keys out of repositories and build logs.
Plan for CI and enterprise hosts
1. Find workflows and services whose remote begins with `git@` or `ssh://`.
2. Record the OpenSSH or embedded library version in each execution environment.
3. Remove forced SHA-1 or old key-exchange settings from SSH config where they are no longer needed.
4. Test clone, fetch, push, submodule checkout, and deployment paths with the real identity.
5. Exercise the two brownout windows and monitor failed SSH handshakes.
6. Document key owners, purpose, host, and replacement date.
GitHub says these changes affect Git clients using SSH and unauthenticated Git protocol users on GitHub Enterprise Server. HTTPS remotes are outside this specific change. GitHub Enterprise Server receives the changes in version 3.25, while the new ML-KEM support arrives in version 3.24.
The short version
Check the SSH client, not only the key. Existing RSA keys can usually continue with SHA-2 signatures, new RSA uploads need 3072 bits, and modern Ed25519 keys are a good default for new integrations. Test every real CI and deployment path before the November and December brownouts.