SSH Key Management Strategies for Security

Key Takeaways:

• RSA-260, an 862-bit number, fell on September 3, 2026 for about $400,000 in GPU time. Eric Lu estimated RSA-1024 at roughly $30 million, within reach of hyperscalers and frontier AI labs.
• RSA-2048 is safe from classical factoring; the genuine near-term threats are short RSA keys and the quantum “harvest now, decrypt later” attack on session key exchange.
• OpenSSH has shipped post-quantum key exchange by default since 9.0 (2022). OpenSSH 10.0 defaults to mlkem768x25519-sha256, and 10.1 warns when a session falls back.
• Signature keys (RSA, ECDSA, Ed25519) have no “harvest now” exposure but must be retired before a cryptographically relevant quantum computer arrives, because Shor’s algorithm breaks all three.
• Real key hygiene, not just key exchange, is the durable fix: most enterprise deployments hold vast numbers of unused and root-privileged keys that never expire.

The First Domino: What Broke in 2026

SSH keys were the first to break. On September 3, 2026, Eric Lu of Cognition factored RSA-260, an 862-bit number from the 1991 RSA Factoring Challenge that had resisted attack for 35 years. The factorization cost about $400,000 in GPU time (4,900 GPU-days, or 13.5 GPU-years) using an optimized general number field sieve, and Lu estimated that a hyperscaler or frontier AI lab could factor an RSA-1024 key for roughly $30 million, as detailed in his writeup of the RSA-260 result.

Two details in that post matter more than the headline number. First, Lu improved the optimization with Devin, Cognition’s autonomous software engineering agent, which handled GPU kernel work and cluster orchestration that would previously have required a multi-month team of specialists. Second, he pointed out that RSA-2048 remains “roughly a billion times harder” than RSA-1024 and “does not appear to be meaningfully affected by this work.” The near-term lesson is that short RSA keys, still common in aging SSH infrastructure, have moved from a theoretical risk to a dollar-quantified one.

The specific risk for SSH is clear. RSA-1024 was deprecated by NIST in 2013, yet it remains in legacy hosts, embedded devices, and old authorized_keys files. RSA-2048 is still the default for compatibility, and it is the key size most enterprises should be auditing right now, not because it is broken but because anything shorter than it is now questionable.

Two Threat Tracks: Classical GPUs and Quantum

The attack surface divides into two categories that require different responses. The classical category is the one that changed in 2026. Lu’s RSA-260 factorization used no quantum hardware and no algorithmic breakthrough, just the general number field sieve adapted to GPUs. Sixteen days later, on September 19, 2026, Anthropic’s Stephen Weis factored RSA-896 using Claude and up to 2,048 GPUs. Neither record affects RSA-2048, but both put RSA-1024 within reach of any organization that already owns a data-center GPU fleet.

The quantum category moves more slowly but causes more damage. A cryptographically relevant quantum computer running Shor’s algorithm would break RSA, ECDSA, and Ed25519 entirely, deriving private keys from public ones through efficient integer factorization and discrete-logarithm solving. The resource estimates for that machine keep falling. In May 2025, Google Quantum AI’s Craig Gidney estimated that factoring RSA-2048 would require fewer than one million physical qubits, a 95 percent reduction from his 2019 estimate of 20 million, per The Quantum Insider’s summary of the paper. In March 2026, research from Caltech and the startup Oratomic put breaking P-256 elliptic-curve cryptography, the type used across SSH’s ECDSA and Ed25519 family, at as few as 10,000 physical qubits, which prompted Cloudflare to pull its internal post-quantum completion target forward to 2029 in its post-quantum roadmap.

The difference between the categories determines what to fix first. Key exchange has a “store now, decrypt later” risk: an attacker can record encrypted SSH sessions today and decrypt them once a quantum computer exists. Signatures do not have this risk. OpenSSH’s own guidance is clear on this point, noting in its post-quantum cryptography page that “there is no analogous store now, decrypt later” risk for signature keys. The order of urgency is therefore: upgrade key exchange first, then retire quantum-vulnerable signature keys before the machine arrives.

How Hybrid Post-Quantum Key Exchange Works

The method that fixes the key-exchange risk is already shipping and enabled by default. OpenSSH introduced its first post-quantum key agreement method, sntrup761x25519-sha512, in release 9.0 in April 2022. That algorithm combines Streamlined NTRU Prime (sntrup761), a lattice-based scheme, with the classical X25519 elliptic-curve key exchange. OpenSSH 9.9 added a second method, mlkem768x25519-sha256, which pairs the NIST-standardized ML-KEM (FIPS 203) with X25519, and made it the default in OpenSSH 10.0 in April 2025.

The term “hybrid” is the key point. Each method combines a post-quantum algorithm with a classical one, so even if the newer post-quantum scheme is later broken by cryptanalysis, the combined result is no weaker than the classical X25519 it replaced. This is a deliberate safety margin, as the OpenSSH project states plainly. GitHub adopted the same approach, rolling out sntrup761x25519-sha512 for SSH access to its Git endpoints on September 17, 2025, while noting that the algorithm is not FIPS-approved, which is why it excludes the US data-residency region, per the GitHub engineering announcement.

The FIPS gap is real and worth tracking. Red Hat closed it in Red Hat Enterprise Linux 10.2 by shipping two additional hybrid methods, mlkem768nistp256-sha256 and mlkem1024nistp384-sha384, which combine ML-KEM with ECDH over the NIST-recommended P-256 and P-384 curves instead of Curve25519. Because every component is FIPS-approved, these let SSH run post-quantum key exchange in FIPS mode, something the upstream sntrup and mlkemx25519 methods cannot do, as described in Red Hat’s post-quantum SSH post.

Upgrading is not enough by itself, and Cloudflare’s roadmap makes the point clearly: once quantum-vulnerable cryptography is disabled, every secret that previously flowed through it, including SSH session keys, has to be rotated, and the upgrade path depends on third parties. Detection matters too. OpenSSH 10.1 warns at connect time when a session is not using post-quantum key exchange, and you can confirm what a given connection negotiated with ssh -v, looking for the “kex: algorithm” line.

Auditing and Rotation: A Working Checklist

The algorithm upgrade solves the key-exchange risk but not the hygiene problem, which is the larger practical vulnerability. The research agrees on how bad the sprawl is. SSH Communications Security reported that as many as 90 percent of SSH keys in its customers’ systems were unused, and 10 percent were granted root access, figures cited in TechTarget’s guide to SSH key management best practices. NIST’s guidance on the subject, NIST IR 7966 on securing automated access management with SSH, recommends setting minimum key lengths and permitted algorithms, defining key lifetimes and expiration, and running continuous monitoring. Those are the same controls that address the quantum and AI threat, because a key you cannot inventory is a key you cannot rotate or retire.

Here is a working checklist, ordered by what an attacker with a GPU fleet or a future quantum machine would target first.

• Inventory every RSA key at 1024 bits or below and treat each as urgent. The 2026 factoring records put RSA-1024 within reach of organizations with data-center GPU fleets. Anything at 1024 bits or below should be rotated to Ed25519 or RSA-3072 immediately.
• Retire DSA and set 3072-bit RSA or Ed25519 as the floor. Ed25519 is smaller, faster, and avoids the RSA-1024 legacy entirely, but it is quantum-vulnerable like everything else in this family, so it is a hygiene upgrade, not a quantum fix.
• Confirm post-quantum key exchange is actually negotiating. Check your OpenSSH version: 10.0 and later default to mlkem768x25519-sha256. Run ssh -Q kex and inspect a live connection to verify the server offers it and the client is not falling back to curve25519-sha256.
• Rotate privileged keys on a fixed schedule and enforce expiry. Long-lived keys with root access are the highest-value targets. A 3 to 6 month rotation for privileged keys, with revocation on employee departure, closes the window where a compromised or soon-to-be-factored key grants indefinite access.
• Separate what is breakable today from what is merely harvestable. Signature keys have no harvest-now exposure, but every live session key does. Fix key exchange first, then schedule signature-key retirement against NIST’s deprecation timelines.
• Track the NIST migration deadlines as program dates. NIST SP 800-57 Part 1 treats 2048-bit RSA as acceptable through 2030, and NIST IR 8547 deprecates quantum-vulnerable systems after 2030 and disallows them after 2035. Those are the outer bounds for retiring RSA and ECDSA signature keys.

One caveat on the timeline. The 2030 and 2035 dates assume hardware and algorithmic progress stays roughly on its current curve. The March 2026 neutral-atom results already pulled several vendors’ internal targets forward, and Gidney’s own framing is worth quoting: he agrees with deprecation after 2030 and disallowal after 2035 “not because I expect sufficiently large quantum computers to exist by 2030, but because I prefer security to not be contingent on progress being slow.” The rotation schedule should not wait for a confirmed machine.

The Series Ahead

This is the first part of a six-part series on how public-key cryptography breaks and what to do about it. The pattern of short keys falling first, public keys becoming the attack surface, and migration being a coordination problem rather than a math problem appears across every system in the series. The next part moves from infrastructure to money: Bitcoin’s use of ECDSA over secp256k1, how on-chain public key exposure through address reuse and UTXO spending creates the same kind of vulnerability at protocol scale, and what the combination of Shor’s algorithm and AI-accelerated classical factoring means for long-term Bitcoin security. The practical advice there matches what applies here: generate fresh addresses, avoid reuse, and watch the post-quantum BIP proposals the way you would watch an OpenSSH release.

For the full series outline, see the series index on borrowed time and public-key cryptography.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Post-Quantum Security for Blockchain Systems

Sources and References

Sources cited while researching and writing this article:

• Factoring RSA-260 | Cognition
• Google Researcher Lowers Quantum Bar to Crack RSA Encryption
• Cloudflare targets 2029 for full post-quantum security
• Post-Quantum Cryptography – OpenSSH
• Post-quantum security for SSH access on GitHub
• Advancing post-quantum capabilities of SSH in Red Hat Enterprise …
• SSH key management best practices and implementation tips