GitHub SSH Changes for 2026: RSA, SHA-1, and ML-KEM

GitHub is changing the cryptography accepted by its SSH service. Beginning October 14, 2026, newly added RSA keys must be at least 3072 bits. GitHub is also removing RSA signatures that use SHA-1 and the diffie-hellman-group-exchange-sha256 key exchange after a brownout period. At the same time, GitHub has added the hybrid post-quantum key exchange mlkem768x25519-sha256 for most GitHub.com environments.

The migration is easy to misunderstand. GitHub is not disabling every RSA public key. The affected ssh-rsa name is a signature algorithm that combines RSA with SHA-1. An existing RSA key can remain usable when the client negotiates an RSA signature with SHA-2. The inventory must therefore include clients and libraries, not only the public keys stored in GitHub.

Teams should test laptops, CI runners, deployment appliances, IDEs, Git libraries, and managed build products before the brownouts. A successful ssh command on one engineer's workstation does not prove that an embedded JSch or libssh2 client can authenticate.

The four changes in plain language

GitHub's September 22, 2026 changelog announces four related changes:

1. The RSA/SHA-1 SSH signature type identified as ssh-rsa will no longer be accepted.
2. The finite-field Diffie-Hellman key exchange diffie-hellman-group-exchange-sha256 will be removed.
3. RSA public keys newly added on or after October 14, 2026 must be at least 3072 bits.
4. GitHub supports the hybrid post-quantum key exchange mlkem768x25519-sha256 on GitHub.com and most GitHub Enterprise Cloud environments.

GitHub says the SSH removals affect SSH remotes, while HTTPS access is unaffected. That gives teams a fallback transport during remediation, though changing transport may also require updating credentials, secret stores, proxy rules, and automation.

The key-size rule is an enrollment rule for new RSA keys. It should still prompt a review of smaller or old keys, but do not conflate that review with the algorithm removal.

RSA keys and the ssh-rsa signature are different

An SSH public key such as ssh-rsa AAAA... identifies the key type. During authentication, a client proves possession of the private key by creating a signature. Older clients use SHA-1 for that signature and advertise the ssh-rsa signature algorithm. Modern clients can use the same RSA key with rsa-sha2-256 or rsa-sha2-512.

OpenSSH added RSA/SHA-2 signature support in version 7.2. When OpenSSH 8.8 disabled RSA/SHA-1 signatures by default, its release notes emphasized that RSA keys were not being eliminated. The same distinction applies to GitHub's server-side removal.

This means key inspection alone is insufficient. A 4096-bit RSA key used by an old client can fail because the client knows only the SHA-1 signature method. A 3072-bit RSA key used by a modern client can continue to work through SHA-2.

Do not add HostkeyAlgorithms +ssh-rsa or PubkeyAcceptedAlgorithms +ssh-rsa as a permanent fix. Those settings re-enable the obsolete SHA-1 path on a client. GitHub's server will no longer accept that path after removal.

Build an inventory from connection paths

Start with systems that initiate GitHub SSH connections. The inventory should name the product, version, SSH implementation, account, repository scope, credential owner, and business criticality.

Common connection paths include:

• Developer laptops using OpenSSH, PuTTY, or an IDE-bundled client.
• GitHub Actions jobs that contact another GitHub host or submodule by SSH.
• Jenkins, TeamCity, Bamboo, and other CI coordinators.
• Deployment platforms that clone a repository during a release.
• Infrastructure automation using Go's SSH package, JSch, libssh2, or libssh.
• Network appliances, code scanners, backup systems, and mirroring tools.
• Containers and long-lived virtual machines with frozen base images.
• Git submodules whose URLs differ from the parent repository.

Search configuration for SSH GitHub URLs:

git remote -v
git config --get-regexp '^url\..*\.insteadof$' || true
git submodule foreach --recursive 'git remote -v'

Also inspect secret managers and deployment settings. A key may be active even if it is absent from a developer's local Git configuration.

Find the actual client implementation

Run version checks in the same environment that performs the clone or push:

ssh -V
git --version
ssh -G git@github.com | grep -Ei 'pubkeyacceptedalgorithms|kexalgorithms'

The operating-system OpenSSH version may not be the relevant client. Java products may use JSch. Go applications may use golang.org/x/crypto/ssh. A library linked into an appliance may use libssh2. An IDE may ship its own implementation.

GitHub's announcement lists these minimum versions as robust migration targets:

Implementation or product	Version listed by GitHub
OpenSSH	7.2p1 or later
Maintained JSch fork	0.1.66 or later
TeamCity	2021.2.3 or later
Go SSH	0.16.0 or later
libssh2	1.11.0 or later
PuTTY	0.82 or later

Treat the table as a starting point. Vendors may add fixes or backports without matching an upstream version exactly. Test the deployed product and read its current vendor guidance.

Test authentication without making a Git change

GitHub documents the standard test:

ssh -T git@github.com

On the first connection, verify the presented host-key fingerprint against GitHub's published SSH fingerprints. A successful authentication prints a message that identifies the GitHub account and explains that shell access is unavailable. GitHub notes that the command exits with status 1 even when authentication succeeds, so automation should evaluate the message carefully.

Use verbose output for diagnosis:

ssh -vvv -T git@github.com

Look for the negotiated key exchange and public-key signature algorithm. Redact usernames, paths, public-key fingerprints, and network details before sharing logs externally.

Then test the real operation from the real product. For a read-only deploy key, run git ls-remote. For a CI integration, trigger a representative build. The generic OpenSSH test cannot validate a Java or Go client that the product uses internally.

Interpret the brownout schedule carefully

GitHub plans temporary brownouts before final removal. The changelog lists brownout dates on November 4 and December 9. During a brownout, incompatible clients should fail, making hidden dependencies visible before permanent enforcement.

The same changelog currently labels the final removal as January 13, 2026, which appears chronologically inconsistent because it follows events in October, November, and December 2026. This article will not silently reinterpret an official date. Teams should monitor the linked GitHub changelog and status communications for a correction or clarification before scheduling their final cutover.

That ambiguity is not a reason to wait. Use October 14 as the first firm control date for new RSA keys and complete compatibility testing before the first November brownout.

Create monitoring for authentication failures during each brownout window. Capture the originating system, client library, repository, and credential. Avoid logging private key material or full secrets.

Choose a key strategy

GitHub's key generation guidance recommends Ed25519 for new keys on compatible systems. Ed25519 keys are small, fast, and avoid the RSA signature ambiguity.

Generate a new personal key with a meaningful comment:

ssh-keygen -t ed25519 -C "developer@example.com"

For environments that require RSA, GitHub's documentation shows 4096 bits:

ssh-keygen -t rsa -b 4096 -C "deploy-system@example.com"

Beginning October 14, a new GitHub RSA key must be at least 3072 bits. A 4096-bit key meets that floor. Confirm that the client uses RSA/SHA-2 before enrolling it.

Follow the cryptographic policy for regulated systems. Some FIPS-constrained environments may have different approved algorithms or vendor requirements. The migration goal is not to replace every key reflexively. It is to remove unsupported clients, obsolete signatures, unmanaged credentials, and unclear ownership.

Rotate credentials without creating an outage

Use an overlap period rather than replacing a key in place:

1. Generate the new key in the system that will use it.
2. Store the private key in the approved secret manager or hardware-backed agent.
3. Add the public key to GitHub with a clear title and minimum repository scope.
4. Test authentication and the actual read or write operation.
5. Update dependent jobs and restart long-lived agents if required.
6. Observe successful use of the new credential.
7. Remove the old key and verify that no job still depends on it.

For deploy keys, remember that one key is usually attached to one repository. Machine users, GitHub Apps, and HTTPS tokens may be better for broader automation. Use the smallest repository and write scope possible.

Review account SSH keys in GitHub and remove keys that are unknown, unused, or tied to retired devices. GitHub provides a key review procedure and shows recent-use information where available.

Distinguish user keys, deploy keys, and host keys

User and deploy keys authenticate a client to GitHub. GitHub's host keys authenticate GitHub to the client. Rotating a user key does not change the host fingerprint that clients should trust, and adding a GitHub host key to known_hosts does not fix an obsolete user-signature algorithm.

Automated systems need a managed known_hosts policy. Fetching host keys from the network immediately before every connection and trusting whatever arrives weakens server authentication. Seed GitHub's published fingerprints through a controlled configuration process and monitor official rotation notices.

Hashed known_hosts entries protect hostnames from casual disclosure if the file leaks, but they do not replace fingerprint verification. Avoid StrictHostKeyChecking=no in CI. It trades a visible setup problem for silent exposure to a machine-in-the-middle attack.

SSH certificates are another distinct mechanism. Some enterprises use a certificate authority to sign short-lived user or host credentials. Confirm how the product implements GitHub access because an internal SSH certificate workflow may end at a gateway that then uses a separate GitHub key.

Assign ownership before rotating

Every machine credential should have an accountable team, repository scope, purpose, creation date, and review date. A comment such as deploy-system@example.com helps during enrollment, but a separate inventory is needed when people change roles or a platform is retired.

Rotation plans should include rollback. Keep the old public key enrolled only for the brief overlap required to prove the new path. If the new client fails during a release, revert the job to the old credential while preserving evidence, then correct the client. Do not leave both keys indefinitely.

For personal keys, use an agent or hardware-backed store where supported and protect the key with a passphrase. For unattended jobs, use the platform's secret manager and restrict who can read or replace the value. File permissions alone are not an adequate ownership model for shared runners.

Fix older Java, Go, and native clients

Embedded SSH libraries create most migration surprises because they are upgraded through the parent product.

For Java, identify whether the product uses the original JSch line or a maintained fork. GitHub lists maintained JSch fork 0.1.66 as a robust minimum. Upgrade the product rather than dropping an arbitrary JAR into a managed installation unless the vendor explicitly supports that action.

For Go services, inspect go.mod and the compiled dependency graph:

go list -m golang.org/x/crypto
go version -m ./path/to/binary

GitHub lists Go SSH 0.16.0 or later. Rebuild, redeploy, and test the exact binary. A source repository with an updated module file does not fix an old binary still running in production.

For libssh2, GitHub lists 1.11.0 or later. Check both the library and the application that links it. Static linking can preserve an old SSH implementation even after the operating system package is upgraded.

Our guide to GitHub Actions workflow execution protections covers the adjacent problem of keeping CI credentials and untrusted workflow changes apart.

Understand the key-exchange removal

SSH uses one algorithm to authenticate identities and another to establish fresh session keys. diffie-hellman-group-exchange-sha256 is a finite-field Diffie-Hellman key exchange. GitHub is removing it as part of the same hardening effort.

Modern clients typically offer alternatives such as Curve25519-based exchange, so many users will never notice. Older libraries or tightly constrained configurations may offer only the removed method.

Use verbose SSH output or the product's diagnostic logs to see what was negotiated. Review custom KexAlgorithms settings in SSH configuration. A copied hardening template can become a compatibility problem if it pins a narrow, aging list.

Do not respond by enabling every legacy key exchange. Upgrade the client and use its secure defaults, then add a narrow configuration only when a documented interoperability requirement exists.

Avoid brittle algorithm pinning

Security baselines sometimes replace a client's default algorithm list with a hand-written list. That can freeze a connection on algorithms that were preferred several years ago and prevent newer hybrid choices from being negotiated. It can also create an outage when a service removes one pinned option.

Prefer a maintained client's defaults. If policy requires an allowlist, generate it from current approved algorithms, document why each item exists, and schedule review. Test the list against GitHub and every other required SSH endpoint before deployment.

Keep authentication algorithms, host-key algorithms, ciphers, message authentication codes, and key exchange in separate fields. Similar names can lead an operator to change the wrong control. Record the final negotiated values from a representative connection instead of assuming the configured first choice won.

What ML-KEM adds to GitHub SSH

mlkem768x25519-sha256 is a hybrid key exchange standardized for SSH in RFC 10042, published in August 2026. It combines ML-KEM-768 with X25519 and derives the session secret from both components.

ML-KEM is the module-lattice key-encapsulation mechanism standardized by NIST in FIPS 203. The hybrid design keeps a well-understood classical component while adding protection intended to resist a cryptographically relevant quantum computer. The session remains protected if at least one component retains its intended security and the combination is implemented correctly.

This addresses the harvest-now-decrypt-later threat: an attacker can record encrypted traffic today and hope to decrypt it after future advances. Source-code transfers and authentication sessions may retain value for years, so transport protection can matter even when a quantum computer does not exist today.

ML-KEM does not replace SSH public keys. It protects key exchange for the session. The user or deploy key still authenticates the client.

Check whether the client negotiates hybrid exchange

OpenSSH 10.0 made mlkem768x25519-sha256 the default client key exchange. OpenSSH 10.1 added warnings when a connection uses a key exchange that is not believed to resist a quantum attack.

List the client's supported key exchanges:

ssh -Q kex | grep mlkem

Inspect a GitHub connection:

ssh -vv -T git@github.com 2>&1 | grep -i 'kex:'

Do not force the hybrid algorithm across a heterogeneous fleet until every required endpoint supports it. Prefer current client defaults and monitor negotiation. GitHub notes that support is not available in every data-residency environment, including the listed US exception at announcement time.

Post-quantum migration affects other protocols too. Our analysis of post-quantum DNSSEC packet migration explains why algorithm strength, message size, and operational compatibility must be considered together.

Separate urgent work from strategic work

The urgent 2026 work is straightforward:

• Upgrade clients that depend on RSA/SHA-1 signatures.
• Remove reliance on the deprecated finite-field key exchange.
• Ensure newly enrolled RSA keys meet the 3072-bit minimum.
• Test every automated connection before brownouts.
• Establish owners and rotation dates for SSH credentials.

Hybrid post-quantum exchange is strategic. Upgrade clients through normal security maintenance, observe whether mlkem768x25519-sha256 is negotiated, and avoid brittle one-off configuration. A team can complete the urgent compatibility migration even if some approved clients do not yet support the hybrid algorithm.

This separation keeps the project measurable. Authentication failures are a 2026 outage risk. Post-quantum adoption is a cryptographic-agility program that will continue as standards and products mature.

Measure migration completion

Define completion using observed connections and owned assets. Useful measures include the percentage of SSH connection paths tested, the number of clients below the supported baseline, keys without owners, RSA keys below the new enrollment floor, and successful runs during each brownout.

Do not use the count of rotated keys as the primary measure. A team can rotate a key and leave the old client library in place, producing the same outage later. The unit of work is the connection path: client implementation, credential, network route, GitHub account, and repository operation.

Keep evidence for critical systems. Record the product version, test date, GitHub target, authentication result, and negotiated algorithms without storing private material. That evidence helps incident responders distinguish a cryptographic compatibility failure from a revoked key, repository permission problem, or network outage.

A migration runbook for engineering teams

Use this runbook before the first brownout:

1. Export all GitHub SSH keys, deploy keys, machine credentials, and known integrations.
2. Find every SSH GitHub remote, including submodules and mirrors.
3. Record the real SSH implementation and version for each connection path.
4. Upgrade anything below GitHub's listed robust versions or obtain vendor confirmation.
5. Test ssh -T where OpenSSH is actually used.
6. Test git ls-remote, clone, fetch, and push as appropriate from each product.
7. Rotate weak, shared, ownerless, or unscoped keys.
8. Prefer Ed25519 for compatible new keys or RSA of at least 3072 bits where required.
9. Watch authentication telemetry during GitHub brownouts.
10. Keep an HTTPS fallback procedure for critical repositories.
11. Confirm current dates on GitHub's changelog before the final enforcement window.
12. Document the negotiated algorithms and schedule the next review.

For broader controls around key ownership, web security, and incident response, see our website security essentials.

Sources and freshness

This guide was verified on September 23, 2026 against GitHub's SSH security announcement, SSH connection test, key generation guide, key review guide, and host fingerprints. Cryptographic details were checked against NIST FIPS 203, RFC 10042, and the official OpenSSH 8.8, 10.0, and 10.1 release notes. Recheck GitHub's timeline because the announcement currently contains a chronologically inconsistent final date.

---