GitHub’s SSH Brownout Starts Nov. 4: Check the Client Before Replacing Keys

An SSH key file and an SSH signature algorithm are related, but they are not the same thing. That distinction is the difference between a targeted compatibility check and needlessly replacing working access credentials across a team.

Two different RSA names cause confusion

GitHub’s notice describes a transition away from SHA-1-based ssh-rsa signatures and older key-exchange options. The string ssh-rsa is also commonly used to describe the RSA public-key format. The format can be used with newer RSA/SHA-2 signatures; GitHub says existing RSA keys can continue when the client negotiates those signatures. The 3072-bit minimum applies to new RSA keys uploaded after Oct. 14, 2026. ^[1]

That means the first diagnostic question is not “how many RSA keys do we have?” It is “which SSH client, key and signature method does each real Git operation negotiate?” Old system libraries, embedded build agents and stale workstation clients may behave differently from a developer’s current laptop.

Dates and algorithm layers

GitHub’s schedule calls for brownouts on Nov. 4 and Dec. 9, 2026, with the affected SHA-1 signature and diffie-hellman-group-exchange-sha256 algorithms removed on Jan. 13, 2027. HTTPS Git remotes are not affected by these SSH handshake changes. The notice also describes a hybrid mlkem768x25519-sha256 key-exchange option on GitHub.com and GitHub Enterprise Cloud data residency, with a stated U.S. exception. ^[1]

Key exchange and account authentication solve separate problems. The hybrid method combines a post-quantum key encapsulation mechanism with X25519 to establish a session secret. NIST FIPS 203 specifies ML-KEM as a key-establishment mechanism; it is not the SSH public-key signature used to identify a GitHub account. ^[3]

Inventory the path that actually runs

Start by checking whether the repository remote uses SSH or HTTPS. For SSH-based workflows, GitHub documents a connection test using ssh -T git@github.com; verbose SSH diagnostics can show which algorithms are offered and selected. Run the check in the same environment as the actual operation: local shell, CI runner, deployment worker or long-lived automation host. ^[2]

Create a small inventory of client versions and key types rather than collecting private-key contents. Confirm that clients support RSA/SHA-2 where RSA keys are used, and that they can negotiate an allowed key-exchange algorithm. Test a representative push and fetch during the brownout windows, or stage a controlled test against a noncritical repository beforehand.

If a client is too old, update its SSH implementation or use an approved HTTPS remote where appropriate. If a new RSA key is genuinely needed, generate it with the required size and update the relevant access records through normal review. Do not send private key material through chat or an issue tracker.

Make the rollout observable

For CI, pin or update the runner image and test SSH behavior before a production workflow depends on it. Record the client version, negotiated signature, key-exchange algorithm and result without logging secret material. For teams with a mix of operating systems, include each distinct client family; one successful laptop test does not cover a minimal container image.

The timeline is long enough for a measured change. Confirm what your clients negotiate, upgrade the clients that need it, and replace keys only when evidence shows a key itself is the issue. Separating identity authentication from session key exchange keeps the remediation focused and helps avoid both surprise outages and unnecessary credential churn.