Developers who connect to GitHub over SSH should check their clients and automation before November 4, 2026, when GitHub plans the first temporary disruption, or brownout, for two legacy SSH algorithms. The change affects older RSA signatures that use SHA-1 and a deprecated Diffie-Hellman key-exchange method. GitHub has also introduced a hybrid post-quantum key-exchange option and stricter requirements for newly uploaded RSA keys.
The important distinction is that GitHub SSH security changes do not require every developer to replace an existing RSA key. Most modern SSH clients already support RSA signatures using SHA-2, and developers using HTTPS Git remotes are outside the scope of this SSH compatibility change.
GitHub’s official security announcement identifies the affected algorithms, compatibility requirements and rollout dates. The first brownout is scheduled for November 4, followed by another on December 9 and permanent removal on January 13, 2027.
GitHub Changelog
What GitHub Is Changing in SSH Security
The migration has four technical components.
First, GitHub is removing support for RSA signatures that use SHA-1, identified by the SSH signature algorithm name ssh-rsa. SHA-1 is no longer considered appropriate for modern cryptographic signature security.
Second, GitHub is removing the diffie-hellman-group-exchange-sha256 key-exchange method. Although its name contains SHA-256, GitHub is retiring this older mechanism in favor of more modern alternatives.
Third, since October 14, newly uploaded RSA SSH keys must contain at least 3,072 bits. Existing keys are not automatically invalidated merely because of that new-upload requirement.
Fourth, GitHub has enabled the hybrid post-quantum key-exchange algorithm mlkem768x25519-sha256 for supported connections to github.com and GitHub Enterprise Cloud with Data Residency, excluding the U.S. region in the initial rollout described by GitHub.
These changes strengthen different parts of an SSH connection. Authentication signatures establish possession of a private key, while key exchange establishes shared secrets for encrypting the session. Improving one does not automatically replace the other.
GitHub SSH Security Changes: The Exact Timeline
| Date | Scheduled change |
|---|---|
| October 14, 2026 | New RSA keys require at least 3,072 bits; hybrid post-quantum key exchange enabled in specified environments |
| November 4, 2026 | First brownout for the two legacy SSH algorithms |
| December 9, 2026 | Second brownout |
| January 13, 2027 | Permanent removal of the two legacy algorithms |
A brownout is a controlled interruption intended to expose incompatible clients before permanent enforcement. GitHub has not specified a universal duration in the announcement, so developers should not assume a particular number of minutes.
For CI/CD pipelines, scheduled jobs and unattended deployments, even a temporary connection failure can be consequential. A failed fetch may prevent a build from starting; a failed push may delay release automation. Testing ahead of November 4 is preferable to diagnosing the issue during a deployment.
Does Your Existing RSA SSH Key Still Work?
For most users, yes.
One of the most confusing aspects of the GitHub SSH security changes is the distinction between an RSA key type and an RSA signature algorithm.
An RSA public key often begins with the text ssh-rsa. That does not necessarily mean the client uses the deprecated SHA-1 signature algorithm. Modern SSH software can use the same RSA key with rsa-sha2-256 or rsa-sha2-512 signatures.
GitHub explicitly states that users with existing RSA keys do not need to generate replacements if their SSH client supports RSA with SHA-2. The relevant issue is usually client compatibility, not the age of the key file.
This distinction matters because unnecessary key replacement can create its own operational risk. Developers may need to update CI secrets, deployment identities, authorized-key records and local configurations. Rotating credentials without a reason can disrupt working systems.
Check your SSH version
On macOS, Linux or Windows systems with OpenSSH installed, run:
ssh -VGitHub lists OpenSSH 7.2p1 as the minimum version with robust default RSA/SHA-2 support for this migration. Other supported software versions in GitHub’s announcement include PuTTY 0.82, libssh2 1.11.0, Go SSH 0.16.0, and TeamCity 2021.2.3.
These are compatibility references for the specific change, not recommendations to remain on those older versions indefinitely. Current maintained versions are preferable because they also contain other security and reliability fixes.
Test authentication without changing repository data
Use:
ssh -T [email protected]For a properly configured account, GitHub normally responds with an authentication message explaining that shell access is not provided. This command does not push code or modify a repository.
If authentication fails, inspect the SSH client’s diagnostic output:
ssh -vT [email protected]Verbose output can help identify the negotiated algorithms and the key being offered. Avoid posting complete logs publicly without reviewing them for usernames, internal paths and other environment details.
Why GitHub Is Removing SHA-1 SSH Signatures
SHA-1 is a cryptographic hash function with known collision weaknesses. Modern security guidance has moved away from using it in digital-signature contexts.
SSH RSA authentication does not become insecure merely because the public key is labeled ssh-rsa. The critical issue is whether the signature operation uses SHA-1 or a stronger algorithm such as SHA-256 or SHA-512.
By removing the SHA-1 signature option, GitHub reduces the possibility that an outdated client and server will negotiate an obsolete authentication mechanism.
For developers, this is an example of cryptographic agility: infrastructure providers periodically retire algorithms as security expectations evolve. The engineering challenge is to migrate without breaking legitimate integrations.
TechnologyHQ’s coverage of the Chrome 155 security update addresses a related operational principle: applying security improvements promptly is important, but understanding the affected components helps teams prioritize the right work.
What Is the New Post-Quantum SSH Algorithm?
The new mlkem768x25519-sha256 mechanism combines two different key-establishment approaches.
ML-KEM-768 is a post-quantum key-encapsulation mechanism based on lattice cryptography. X25519 is an established elliptic-curve key-agreement mechanism. A hybrid design combines their contributions to derive session key material.
The motivation is to protect confidentiality against both conventional attackers and future quantum-computing threats. The hybrid approach also avoids relying entirely on the newer post-quantum component.
This does not mean practical quantum computers can currently break ordinary SSH connections at scale. The migration is precautionary: cryptographic infrastructure is being prepared for future capabilities, particularly where information intercepted today could remain sensitive for years.
Does post-quantum SSH require a new authentication key?
Not necessarily.
The hybrid algorithm concerns key exchange, not the RSA, Ed25519 or ECDSA key used to authenticate a GitHub account.
GitHub says compatible SSH clients can negotiate the new key-exchange mechanism automatically when configured to prefer it. Older clients can continue using other supported key-exchange algorithms.
The immediate November 4 compatibility issue is the removal of the two specified legacy algorithms, not a requirement that every client support ML-KEM.
GitHub SSH Security Changes and CI/CD Pipelines
The greatest operational risk may come from systems developers rarely inspect.
An engineer’s laptop might run a recent OpenSSH version, while a build container still uses an outdated SSH library. A self-hosted runner, deployment appliance or embedded Git client may depend on the deprecated signature or key-exchange algorithm.
This creates a hidden dependency: a project can appear healthy during local development while its automated release pipeline fails.
What engineering teams should audit
Start by identifying Git remotes that use SSH:
git remote -vAn SSH remote commonly looks like:
[email protected]:organization/repository.gitAn HTTPS remote commonly looks like:
https://github.com/organization/repository.gitGitHub says HTTPS Git remotes are not affected by these SSH algorithm changes.
Next, identify the software performing each connection. A build system may use OpenSSH directly, a Java SSH library, a Git library or an embedded client. The SSH version on the developer’s workstation does not prove the version inside a container or CI runner.
Finally, perform an authorized test fetch or SSH authentication from the actual execution environment. Testing only from a laptop is insufficient when automation runs elsewhere.
TechnologyHQ’s recent article about GitHub Copilot Fusion and AI development workflows provides another perspective on modern developer tooling. As automation becomes more sophisticated, its reliability still depends on fundamental infrastructure such as authentication, repository access and supported protocols.
How to Prepare for the November 4 Brownout
The safest migration is incremental.
Begin by recording which systems connect to GitHub through SSH. Include developer workstations, self-hosted runners, build servers, deployment scripts, IDE integrations and service accounts.
Check their SSH implementations against GitHub’s compatibility guidance. Upgrade obsolete software through its supported maintenance process rather than weakening server-side security or forcing deprecated algorithms.
Run connection tests from each representative environment and confirm that the client negotiates a supported signature and key-exchange method.
For newly generated authentication keys, GitHub recommends Ed25519 when supported. If an RSA key is necessary for compatibility with other systems, generate one that meets the 3,072-bit minimum for new uploads.
Do not delete working keys before confirming that their replacements are installed everywhere they are required. Credential changes should be staged, documented and reversible.
What to do if an SSH connection fails
First, determine whether the failure is related to algorithm negotiation or a different problem such as missing permissions, a revoked key, DNS resolution or network connectivity.
Verbose SSH output can distinguish many of these cases. An error indicating no matching host-key, signature or key-exchange algorithm points toward a compatibility issue, but the exact message matters.
If the client is outdated, update it and retest. If the environment cannot be updated immediately, assess whether an approved HTTPS remote with appropriate authentication can serve as a temporary alternative. Do not disable host-key verification or add insecure SSH options merely to restore connectivity.
For managed systems, involve the administrator responsible for the relevant SSH library or build environment.
What About GitHub Enterprise Server?
GitHub’s announcement also identifies version requirements for GitHub Enterprise Server.
The company says the broader algorithm-removal changes are associated with GitHub Enterprise Server 3.25, while the new hybrid post-quantum key-exchange capability is introduced in version 3.24.
Administrators should check their actual Enterprise Server version and release documentation rather than assume the public github.com schedule maps directly onto every self-hosted deployment.
This distinction is particularly important in regulated environments, where upgrades may require formal testing and change approval.
Why the Migration Matters Beyond GitHub
The GitHub SSH security changes illustrate a broader transition in secure developer infrastructure.
Authentication systems must stop relying on legacy cryptographic mechanisms, while network protocols need a path toward post-quantum protection. At the same time, compatibility changes can affect software supply chains, release pipelines and automated infrastructure.
The best response is not emergency key rotation across an entire organization. It is an inventory-driven process: identify the affected clients, test negotiation, update unsupported software and preserve working automation.
That approach also aligns with the general security practices discussed in TechnologyHQ’s cybersecurity guide for remote workers, particularly software maintenance and secure authentication.
Frequently Asked Questions
Will GitHub SSH stop working on November 4?
Not for all users. GitHub has scheduled a temporary brownout affecting clients that depend on two deprecated algorithms. Modern compatible clients should continue working.
Do I need to replace my RSA SSH key?
Usually not. Existing RSA keys can continue working when the SSH client uses RSA signatures with SHA-2. The 3,072-bit requirement applies to newly uploaded RSA keys.
Does this affect HTTPS Git connections?
No. GitHub explicitly states that Git remotes beginning with https:// are outside the scope of these SSH changes.
Is post-quantum SSH mandatory?
No. GitHub is adding a hybrid key-exchange option for compatible clients. Older clients can negotiate other supported mechanisms.
When will the old algorithms be permanently removed?
GitHub’s published schedule lists January 13, 2027, following brownouts on November 4 and December 9, 2026.
The Bottom Line
The GitHub SSH security changes are a necessary cryptographic modernization, but their immediate impact is primarily a compatibility issue for older developer tools and automated systems.
With the first brownout scheduled for November 4, teams should test SSH access now, especially from CI/CD environments. Most modern clients require no key replacement. The priority is to identify outdated software, confirm SHA-2-compatible authentication and avoid disruptions when GitHub removes legacy algorithms permanently in January 2027.
Ingrid Maldine is a business writer, editor and management consultant with extensive experience writing and consulting for both start-ups and long established companies. She has ten years management and leadership experience gained at BSkyB in London and Viva Travel Guides in Quito, Ecuador, giving her a depth of insight into innovation in international business. With an MBA from the University of Hull and many years of experience running her own business consultancy, Ingrid’s background allows her to connect with a diverse range of clients, including cutting edge technology and web-based start-ups but also multinationals in need of assistance. Ingrid has played a defining role in shaping organizational strategy for a wide range of different organizations, including for-profit, NGOs and charities. Ingrid has also served on the Board of Directors for the South American Explorers Club in Quito, Ecuador.
