Skip to main content
Software engineering · SSH · Delivery reliability

GitHub SSH Migration 2026:
A Test Plan for Development and CI

Published: 15 October 2026·Zaid Aljbour, Managing Director·12 min read

The GitHub SSH migration in 2026 is primarily an inventory and compatibility test. Since 14 October, GitHub has accepted newly uploaded RSA keys only when they are at least 3072 bits and has supported a hybrid post-quantum key exchange. Brownouts for two legacy methods follow on 4 November and 9 December, before their removal on 13 January 2027.

The largest risk is unlikely to be a current developer laptop. It sits in less visible paths: self-hosted CI runners, old Java libraries, build appliances, deploy keys, container images, and submodules. A successful laptop test therefore does not prove the delivery chain is ready.

Short answer: Inventory every process that connects to GitHub over SSH. Verify the client version, negotiated signature, and key exchange. Test checkout, fetch, submodules, and push from the real runtime. Replace only proven incompatibilities, then use the brownouts as controlled failure tests.

What GitHub is changing and when

DateChangeOperational effect
14 October 2026New RSA keys require at least 3072 bits; mlkem768x25519-sha256 becomes availableTest new key and automation paths against the active requirements
4 November 2026First brownout for SHA-1 ssh-rsa and diffie-hellman-group-exchange-sha256Incompatible clients should become visible under control
9 December 2026Second brownoutFind remaining exceptions and forgotten runtimes
13 January 2027The two legacy methods are removedAffected SSH paths fail permanently

GitHub identifies Git clients connecting over SSH as affected, plus the unauthenticated Git protocol on GitHub Enterprise Server. Remotes beginning with https:// are outside this specific change. Still inspect submodules and scripts: an HTTPS primary remote does not rule out additional SSH URLs.

RSA keys and ssh-rsa are not the same thing

The confusing name ssh-rsa refers here to the legacy RSA signature using SHA-1. The same RSA public key can be used with the newer rsa-sha2-256 and rsa-sha2-512 signatures. RFC 8332 standardises exactly that separation: the key format remains ssh-rsa, while the signature uses SHA-256 or SHA-512.

This produces an important migration rule: do not rotate an existing RSA key solely because of its file header or displayed key type. The material question is which signature algorithm the real client negotiates. A current client normally selects RSA-SHA-2 automatically. An old embedded system may offer only SHA-1 while using the same key.

GitHub's new 3072-bit threshold applies to RSA keys newly uploaded from 14 October. When a new access path has no RSA compatibility requirement, teams can follow GitHub's recommendation and use Ed25519. Where RSA remains necessary, generate at least 3072 bits and document the compatibility reason.

Which GitHub SSH clients should be checked first

GitHub publishes minimum versions for robust RSA-SHA-2 support under default configuration. They include OpenSSH 7.2p1, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0, and PuTTY 0.82; for JSch, GitHub points to version 0.1.66 of a maintained fork. These numbers begin an inventory. They do not prove a particular workload.

Connection pathCommon blind spotRequired evidence
Developer machinesMultiple SSH installations from the OS, Git bundle, or WSLVersion and verbose test from the terminal actually used
CI runnersOld base image or embedded libraryCheckout, fetch, submodules, and artefact push in the runner
Deploy keysKey consumer and runtime are undocumentedRepository, owner, client, expiry, and revocation test
Build and network appliancesThe SSH stack does not follow system OpenSSHVendor statement plus observed negotiation
Containers and scheduled jobsRarely started images escape daily operationsTest for every image and scheduled path

The prioritisation is ATMAN analysis. Start with production write paths and rarely executed recovery or release jobs. A read failure during a local clone is obvious; a restore job launched only during an incident can remain incompatible for months.

How to test GitHub SSH in six steps

  1. Inventory remotes and dependencies. Use git remote -v for primary remotes, then inspect .gitmodules, pipeline configuration, and deployment scripts for GitHub SSH URLs.
  2. Identify the real implementation. Run ssh -V in the same shell, container, or runner that later invokes Git. For libraries, record the package and version.
  3. Inspect keys without collecting secrets. Record the public key's type, bit length, fingerprint, owner, and purpose, for example with ssh-keygen -lf KEY.pub. Private keys and passphrases do not belong in the inventory.
  4. Observe negotiation. Run ssh -vvT [email protected] in a controlled environment. Check for RSA-SHA-2 and a supported key exchange instead of reading only the final success line. GitHub's successful authentication test intentionally exits with status 1 because it does not provide shell access.
  5. Exercise the actual Git path. Perform a read-only fetch, initialise submodules, and—in an approved test repository—exercise the write path. An SSH handshake alone does not fully cover permissions, agents, proxies, or embedded Git clients.
  6. Prepare the brownout and rollback. Name the owner, test window, expected failure, and a time-limited fallback. HTTPS can be an alternative for selected Git workflows, but it needs its own token and secret controls.

How to interpret post-quantum SSH

The new name mlkem768x25519-sha256 identifies a hybrid key exchange. RFC 10042 combines ML-KEM-768 with X25519 and derives the SSH shared key from both. Here, “hybrid” means the connection does not depend exclusively on a new post-quantum algorithm.

GitHub says the addition should normally require no user action: supporting clients negotiate the method, while older clients fall back to another offered method. GitHub's announcement also excludes the US region of GitHub Enterprise Cloud with Data Residency. Observe a real connection rather than inferring the negotiated algorithm from a product label.

This change complements but does not replace a post-quantum TLS migration. SSH and TLS have separate protocols, libraries, endpoints, and operating evidence. Both benefit from a reproducible Cloud and DevOps release process and a risk-based security architecture.

A decision matrix for the migration

  • Current client, existing RSA key, RSA-SHA-2 observed: keep the key, document the evidence, and test a brownout.
  • Legacy client without RSA-SHA-2: upgrade the client or library; if that is impossible, test an Ed25519 or ECDSA path for compatibility.
  • New RSA key required: generate at least 3072 bits, test upload and revocation, and record the owner.
  • Unknown deploy key: do not replace it blindly. Identify the repository, consumer, and shutdown path before rotating it in a controlled window.
  • HTTPS remotes only: record the path as not directly affected, while checking submodules and embedded dependencies separately.

Frequently asked questions about the GitHub SSH migration

Do existing RSA keys need to be replaced for GitHub?

Not merely because GitHub is removing ssh-rsa. An existing RSA key can continue when the SSH client signs with RSA-SHA-2. GitHub's 3072-bit minimum applies to new RSA keys uploaded from 14 October 2026.

How do you check whether a GitHub SSH client is affected?

Identify the SSH implementation and version that the workload actually uses, inspect its offered signature and key-exchange algorithms, and run a verbose test connection to GitHub. Repeat the test from CI runners, appliances, and containers rather than relying on a developer laptop.

Are HTTPS remotes affected by the GitHub SSH migration?

No. GitHub states that Git remotes beginning with https:// are not affected by these SSH changes. Teams should still inspect submodules, deployment scripts, and tools for hidden SSH URLs.

Does ML-KEM need to be enabled manually for GitHub SSH?

Usually not. Supporting clients negotiate the hybrid key exchange automatically, while older clients fall back to other supported methods. The urgent task is removing obsolete signature and key-exchange paths.

Start with one complete connection path

Select one critical build or deployment path. Produce evidence for its remote, runtime, client version, public key, negotiated algorithms, successful Git workflow, and revocation. Only then repeat the method for other runners and devices. This turns the GitHub SSH migration in 2026 into a controlled compatibility change rather than an unplanned release outage.

Sources and methodology

This article separates GitHub's published timeline and the IETF protocol foundations from ATMAN's inventory, testing, and decision model. The checklist is technical analysis, not a GitHub requirement or a guarantee for every SSH implementation. All sources were accessed on 15 October 2026.