GitHub SSH Brownout Nov. 4 Blocks SHA-1 ssh-rsa and DH KEX

GitHub's SSH changes bundle three removals and one addition​

GitHub's announcement covers four separate changes that reach Git users on different dates:

• GitHub is removing RSA signatures that use SHA-1, the ssh-rsa signature type. This includes [email][email protected][/email] certificates signed with SHA-1.
• GitHub is removing the diffie-hellman-group-exchange-sha256 key exchange mechanism.
• New RSA SSH keys uploaded after October 14, 2026 must be at least 3,072 bits. This applies to both signing keys and authentication keys.
• GitHub is adding the post-quantum key exchange mlkem768x25519-sha256 for SSH sessions on github.com and GitHub Enterprise Cloud with Data Residency. The U.S. data-residency region is excluded.

GitHub gives a short reason for each. It calls the Diffie-Hellman group exchange a slow, little-used algorithm that advances in quantum computing could break. It is dropping SHA-1 because the hash is known to be weak. It chose 3,072-bit RSA to meet 128-bit security requirements. ML-KEM, GitHub says, is newer, faster and secure against quantum computers. That performance claim comes from GitHub alone; nobody has published independent measurements of it for this deployment.

Scope is narrow. GitHub says only two groups are affected: people connecting with a Git client over SSH, and people using the unauthenticated Git protocol on GitHub Enterprise Server. If your Git remotes start with https://, none of this affects you. The announcement doesn't cover SSH servers you run yourself or other SSH services. It covers how GitHub's Git endpoints negotiate cryptography.

The October-to-January brownout calendar, and a date that can't be right​

GitHub's timeline:

The last row is a mistake. January 13, 2026 comes before the announcement itself and before both brownouts. The obvious reading is January 13, 2027, but GitHub hasn't corrected the entry, so treat that year as your inference until GitHub confirms it. In practice the December 9 brownout is the latest safe point to have everything fixed.

A brownout is a temporary, deliberate removal of a feature so anything that still depends on it fails loudly while there's still time to fix it. GitHub hasn't said how long each brownout lasts or whether it applies to all traffic. Don't assume a particular window. If an overnight CI job or scheduled mirror fails on November 4 or December 9 with a key-exchange or authentication error, these changes are the first thing to check.

GitHub Enterprise Server follows a different schedule tied to releases. GitHub says all of the changes arrive in GHES 3.25, except mlkem768x25519-sha256, which arrives earlier in GHES 3.24. GHES admins therefore control their own timing through upgrades. It also means a 3.25 upgrade will enforce the removals on internal clients, so it should be tested like any other breaking change.

The ssh-rsa name is two different things​

ssh-rsa means two different things, and that causes most of the confusion. GitHub points this out itself. As a key type, ssh-rsa is the label on every RSA public key, no matter how it signs. As a signature type, ssh-rsa means an RSA signature using SHA-1. Only the second one is going away. The replacement signature types are rsa-sha2-256 and rsa-sha2-512, which use SHA-256 and SHA-512.

The standards explain why this is so muddled. RFC 8332, the IETF document that added SHA-2 RSA signatures to SSH in 2018, notes that the original SSH specification defined ssh-rsa as RSA with SHA-1. It says those original algorithms are now considered deficient. Because an RSA key doesn't depend on which hash signs with it, RFC 8332's new algorithms reuse the existing ssh-rsa public-key format and even keep the literal string "ssh-rsa". That's why existing RSA keys work with SHA-2 signatures without being re-encoded, and their fingerprints don't change.

For developers, this means you don't need a new key. GitHub says all RSA keys can sign with all hash algorithms, and that most SSH implementations supporting RSA with SHA-2 pick it automatically. Other projects describe the change the same way. The maintainers of JSch, a Java SSH library, noted when discussing disabling SHA-1 by default that doing so would not unequivocally disable the use of ssh-rsa type keys themselves, as they can still be utilized with the rsa-sha2-256 (RSA/SHA256) & rsa-sha2-512 (RSA/SHA512) signature schemes. A public key line starting with ssh-rsa AAAA… in your GitHub settings is not a warning sign.

Certificates are the exception worth checking. GitHub specifically lists [email][email protected][/email] certificates using SHA-1. Organizations running an SSH certificate authority should check how their CA signs. OpenSSH's own release notes, cited in a GitHub Docs issue, explain why OpenSSH stopped accepting RSA/SHA-1 for certificate signatures: Certificates are at special risk to the aforementioned SHA1 collision vulnerability. The same notes say OpenSSH will use the rsa-sha2-512 signature algorithm by default when the ssh-keygen(1) CA signs new certificates.

This finishes work GitHub started years ago. GitHub's 2021 post on Git protocol security announced changes to which keys are supported in SSH and removing unencrypted Git protocol, with the same wording that only SSH users are affected and HTTPS remotes are not. That round left some SHA-1 RSA use in place, and bug reports from the time show the rollout discontinuing support for SHA-1 RSA ssh keys as of 2022-1-11. This announcement closes what was left.

Which clients meet the RSA/SHA-2 bar​

GitHub lists minimum versions that support RSA with SHA-2 reliably under default configuration:

A few entries need attention. The OpenSSH minimum is very old, so any supported Linux distribution, macOS release or recent Git for Windows install should pass easily. The PuTTY minimum of 0.82 is much more recent. On Windows, where developers often route Git through PuTTY's plink and the Pageant key agent, PuTTY is the most likely place to find a stale version. The libssh2 1.11.0 line matters because libssh2 sits under many GUI Git clients and language bindings, often without the user knowing. In the 2021 rollout, bug trackers for Git GUIs already flagged that libssh2 doesn't have support for SHA-2 RSA in the versions those apps bundled.

The JSch fork detail matters for Java shops. GitHub names version 0.1.66 of a particular fork. The original JSch line isn't a safe baseline. Jenkins plugins, older Eclipse-based tools and in-house Java utilities that embed JSch should be checked for which one they actually ship.

The table isn't complete, and GitHub doesn't claim it is. Python's Paramiko, .NET's SSH.NET and other libraries aren't listed. Both projects have long-running upstream work on the transition: Paramiko contributors proposed rsa-sha2-256 and rsa-sha2-512 as a drop-in replacement for the deprecated ssh-rsa algorithm, and SSH.NET has tracked removing SHA-1 signatures. GitHub gives no version guidance for either, so test them directly rather than assume.

For software that really can't be upgraded, GitHub suggests switching that client to an Ed25519 or ECDSA key. It says every Ed25519 and ECDSA key it supports is strong and will keep working indefinitely. That makes key replacement the fallback when upgrading isn't possible. Upgrading the client comes first.

Key exchange: the Diffie-Hellman removal and the ML-KEM addition​

The other two changes affect key exchange, the step at the start of every SSH connection where client and server agree on the session keys that encrypt the traffic. This is separate from user authentication. Your key type decides how you prove who you are. The key exchange algorithm decides how the channel is secured. One practitioner guide puts it this way: your SSH key type (Ed25519) and your SSH key exchange algorithm (KEX) are separate settings. Moving to Ed25519 doesn't change which key exchange your client offers.

For the diffie-hellman-group-exchange-sha256 removal, GitHub says any implementation in its compatibility table that supports RSA with SHA-2 should also support a strong alternative key exchange. Only clients that offer nothing else will break. Those will mostly be the same old libraries that fail the RSA/SHA-2 check, so a single inventory covers both removals.

mlkem768x25519-sha256 is an addition, and GitHub says it shouldn't require any user changes. Clients configured to prefer it will use it automatically, and older clients fall back to an older key exchange. The name describes a hybrid: ML-KEM-768, the key-encapsulation mechanism NIST standardized in FIPS 203 in August 2024, combined with the classical X25519 elliptic-curve exchange, hashed with SHA-256. NIST describes ML-KEM as currently believed secure even against attackers with a quantum computer. It defines three parameter sets, from ML-KEM-512 to ML-KEM-1024, in order of increasing strength and decreasing performance, and 768 is the middle one. As a general property of hybrid designs, which neither GitHub nor NIST spells out here, pairing it with X25519 keeps the classical protection in place even if the newer algorithm is ever weakened.

GitHub isn't picking a niche algorithm. A Go project proposal notes that OpenSSH has added support for mlkem768x25519-sha256, combining ML-KEM (FIPS 203) with X25519. mlkem768x25519-sha256 is the present default key exchange algorithm on OpenSSH. That proposal also shows why server support matters to ordinary users: OpenSSH 10.1 warns when a connection lacks post-quantum key exchange, telling users This session may be vulnerable to "store now, decrypt later" attacks. In a store-now, decrypt-later attack, someone records encrypted traffic today and decrypts it once quantum computers can break the classical exchange. For source code and credentials passing over Git, that's the threat the addition targets.

Coverage has one clear gap: GitHub Enterprise Cloud with Data Residency in the U.S. region won't get mlkem768x25519-sha256 on October 14. GitHub gives no reason and no later date. Organizations that chose U.S. data residency for compliance should note it. On GHES, ML-KEM arrives in 3.24.

What this means for you: audit SSH clients before the November 4 brownout​

Whether you need to act depends on how your machines and pipelines connect to GitHub. Developers on HTTPS remotes can stop reading. Individual developers on a current OpenSSH or a recent Git for Windows are almost certainly fine. The real work is for teams with CI/CD servers, self-hosted runners, deployment scripts, Java or Python tooling, and GHES appliances heading for 3.25.

Start by finding where SSH to GitHub actually happens, including library-based clients that never call the ssh binary. Compare each one against GitHub's version table. With OpenSSH, ssh -Q kex lists the key exchange algorithms your client supports, so you can confirm it has alternatives beyond diffie-hellman-group-exchange-sha256. Running a connection in verbose mode, which is standard OpenSSH behavior rather than something GitHub describes, shows the key exchange and signature algorithm actually negotiated. For library-based clients, the brownouts are the most reliable test. Make sure someone is watching job failures on November 4.

On key size, the 3,072-bit rule applies to RSA keys uploaded after October 14. GitHub's announcement doesn't say existing smaller RSA keys will be revoked, so don't read that into it. Any new key a script or onboarding process generates must meet the minimum. For new keys, GitHub recommends Ed25519 wherever possible, and RSA only when another service requires it.

• Git remotes that start with https:// are unaffected by all four changes.
• Existing RSA keys don't need replacing. The client just has to sign with rsa-sha2-256 or rsa-sha2-512, which OpenSSH 7.2p1+, PuTTY 0.82+, libssh2 1.11.0+, Go SSH 0.16.0+ and TeamCity 2021.2.3+ handle by default.
• Java tooling that embeds JSch should be checked for the maintained fork at 0.1.66 or later, because the original JSch line isn't a safe baseline.
• New RSA keys uploaded to GitHub after October 14, 2026 must be at least 3,072 bits, and Ed25519 is GitHub's preferred choice for any new key.
• SSH certificate authorities that still sign with RSA/SHA-1 need to move to SHA-2 before the removal.
• GHES admins should treat the 3.25 upgrade as the enforcement point for the removals. ML-KEM support arrives in 3.24.

These changes finish a SHA-1 retirement GitHub began in 2021, and they put post-quantum key exchange on one of the busiest SSH endpoints anywhere, in line with the OpenSSH default. For most users, October 14 will pass without notice, and newer clients will quietly negotiate ML-KEM. The November 4 and December 9 brownouts will expose whatever old client is still hidden in a build farm. The permanent cutoff will follow in January once GitHub corrects the year it published, which is almost certainly 2027.