GitHub SSH brownout: find legacy algorithms before November 4

A scheduled failure is better than a surprise

GitHub is modernizing its SSH security. The first brownout is scheduled for November 4, 2026: connections that still require the old RSA signature with SHA-1 or diffie-hellman-group-exchange-sha256 key exchange are expected to fail during the test window. A second brownout is planned for December 9, followed by final removal on January 13, 2027.

This is not a reason to rotate every key in a hurry. It is a reason to find the clients that are really in use. Developer laptops are often current; forgotten build images, self-hosted runners, deployment appliances, and embedded Git libraries may not be.

The right preparation is inventory, measurement, and a tested update — not a global exception that restores weak algorithms.

What GitHub is changing

GitHub announced four relevant changes:

• The RSA signature ssh-rsa with SHA-1 is being removed.
• diffie-hellman-group-exchange-sha256 is being removed as a key-exchange method.
• New RSA keys uploaded since October 14, 2026 must be at least 3072 bits.
• mlkem768x25519-sha256 is being added as a post-quantum key exchange, with the regional exception documented by GitHub.

HTTPS remotes and pushes over HTTPS are not affected. The change matters for SSH connections to GitHub and for certain unauthenticated Git connections to GitHub Enterprise Server.

An RSA key and ssh-rsa are not the same thing

The most confusing detail is the name ssh-rsa. It may refer to the RSA key type or to the old RSA-with-SHA-1 signature. GitHub is removing the weak signature, not automatically rejecting every existing RSA key.

An existing RSA key can continue with rsa-sha2-256 or rsa-sha2-512 when the client and library support those signatures. GitHub explicitly says affected users do not need to generate a replacement key by default.

In practice, the key is often fine. The old SSH client is the component that offers only ssh-rsa with that key.

Who should inspect most carefully

Risk tends to live where software is rarely updated:

• self-hosted CI runners with old operating-system images;
• Docker images that have pinned OpenSSH or Git for years;
• build tools with embedded JGit, libgit2, or custom SSH implementations;
• deployment appliances and NAS devices;
• old IDEs with bundled SSH clients;
• automation that ships its own ~/.ssh/config with legacy exceptions;
• GitHub Enterprise Server environments with mixed client generations.

A green test on one laptop proves only that one laptop works.

Build a reliable inventory in ten minutes

Start with connections, not key files:

1. Run git remote -v to find repositories using SSH instead of HTTPS.
2. Run ssh -V to capture the OpenSSH version actually executed.
3. Run ssh -Q PubkeyAcceptedAlgorithms to inspect supported signatures.
4. Run ssh -Q kex to list available key-exchange methods.
5. Run ssh -G github.com to print the effective configuration after all includes.
6. Run ssh -vvT git@github.com for a diagnostic handshake and inspect the negotiated methods.

Verbose logs may contain hostnames, usernames, paths, and key fingerprints. Do not paste them into public tickets or chat channels without review.

Test CI and deployments where they actually run

Run diagnostics inside the runner image, not just on its host. For containerized jobs, a temporary audit step should capture at least:

• ssh -V output;
• Git version and the SSH implementation it invokes;
• remote scheme;
• effective host configuration;
• result of a read-only authentication test;
• base image name and digest.

One successful Linux runner is not enough for a matrix pipeline. macOS, Windows, ARM runners, and old release jobs may load different clients. The same applies to production deployments that run outside normal CI.

The safe fix is an update, not a legacy exception

If a client only supports the removed methods, use this order:

1. Update OpenSSH, Git, or the embedded SSH library.
2. Rebuild the stale base image and roll it out by digest.
3. Remove configuration that accidentally excludes modern algorithms.
4. If necessary, create a new Ed25519 or sufficiently large RSA key and rotate it deliberately.
5. Remove the old key only after a successful parallel test.

A global line that re-enables ssh-rsa preserves the problem and may weaken connections to other hosts. A temporary exception belongs, at most, in a host-specific, time-limited recovery procedure with a named owner.

Similar errors point to different failures

During a brownout, similar symptoms may have different causes:

• no matching host key type concerns server identity;
• no mutual signature algorithm concerns the user-key signature;
• no matching key exchange method concerns session-key establishment;
• Permission denied (publickey) can also mean the wrong key, agent, or account.

That is why ssh -vv is more useful than blindly changing configuration. The negotiation phase identifies the right fix.

Use the brownout as a controlled test day

A brownout is a free rehearsal for January. Plan it like a small change window:

• name owners for CI, deployments, and developer access;
• prioritize critical repositories and release paths;
• fetch a known commit before the window;
• watch error rates and failed jobs during the window;
• correlate logs with runner image and client version;
• reproduce fixes in an updated image the same day;
• add findings to a runbook for December 9 and January 13.

The test passes only when rare paths work too: hotfix deployment, rollback, tag signing, and disaster-recovery runners.

A small test prevents a large January incident

Every relevant execution environment should have a read-only automated smoke test. It can read a known public or internal repository ref and fail clearly on SSH negotiation errors.

Record the client version, but do not publish private keys or complete verbose logs as build artifacts. A daily run until January is more valuable than one screenshot from October.

If you use several Git hosts, test them independently. GitHub's removal says nothing about the policy of your internal Git server.

Our 48-hour plan

Before November 4, we would:

1. Inventory SSH remotes and production-critical jobs.
2. Capture every runner image with its client version and digest.
3. Execute read-only handshakes from each environment.
4. Rank legacy hits by business criticality.
5. Update images and libraries, then run parallel tests.
6. Assign brownout monitoring and an available owner.
7. Schedule the second rehearsal for December 9 now.

That turns an announced cutoff into ordinary maintenance.

Conclusion

GitHub's SSH change is technically manageable. The real risk is invisible clients that disappeared from the inventory years ago.

Counting key files misses old signature and key-exchange implementations. Measuring from every real runtime finds the problem before the brownout and lets teams solve it with a normal update instead of re-enabling weak cryptography in January.

Primary sources

• GitHub Changelog: Security improvements for SSH
• GitHub Docs: Testing your SSH connection
• OpenBSD manual: ssh_config
• OpenBSD manual: ssh