SSH 'not using a post-quantum key exchange algorithm' warning explained

The line "WARNING: connection is not using a post-quantum key exchange algorithm" comes from the OpenSSH client, version 10.1 or later. It means the key exchange negotiated with the server was not one of the two hybrid post-quantum algorithms OpenSSH enables by default, mlkem768x25519-sha256 or sntrup761x25519-sha512. The session is still encrypted and works as before; the warning is about traffic that could be recorded now and decrypted later if a large enough quantum computer is ever built.

The proper fix is on the server: a newer SSH server, or a KexAlgorithms list that no longer leaves the hybrid algorithms out. If you cannot change the server, you can mute the message for that host only with WarnWeakCrypto no-pq-kex. In our check on 5 October 2026, github.com, gitlab.com and bitbucket.org all negotiated a post-quantum key exchange, while Azure DevOps did not, so Azure DevOps remotes and older self-hosted servers are the usual sources of the warning in Git.

The full message has three lines. After the first one, the client says the session may be exposed to "store now, decrypt later" attacks, suggests the server may need an upgrade and points to the OpenSSH post-quantum page. Any tool that runs ssh underneath shows it, so many people first see it in git fetch, git push, scp or rsync output.

What the warning actually means

Every SSH session starts with a key exchange, in which client and server derive the keys that protect the rest of the connection. Classical methods such as curve25519-sha256, ecdh-sha2-nistp256 and the diffie-hellman groups depend on mathematical problems that a cryptographically relevant quantum computer is expected to solve. No such machine exists yet. The OpenSSH project cites estimates of 5 to 20 years, with many observers expecting one in the mid-2030s.

The risk is retroactive. Someone who captures encrypted SSH sessions today can keep them and try to decrypt them once that hardware exists. This is the "store now, decrypt later" (or "harvest now, decrypt later") scenario the warning names. It matters most for data that stays sensitive for years: source code, credentials typed inside a session, database exports.

Both algorithms are hybrids. Each pairs a post-quantum scheme with classical X25519: ML-KEM, which NIST standardised as FIPS 203 in August 2024, or Streamlined NTRU Prime. If the post-quantum half were ever broken, the exchange would still be as strong as X25519 on its own.

The warning covers key exchange only. Host keys and user keys (RSA, ECDSA, Ed25519) are used for signatures. OpenSSH notes that most signature algorithms in use today, RSA and ECDSA included, could also be broken by a quantum computer, but that creates no store-now-decrypt-later risk for traffic already sent, so keys are not part of this message.

How OpenSSH got here

• OpenSSH 8.9 (February 2022) added sntrup761x25519-sha512@openssh.com to the default list, after the elliptic-curve methods.
• OpenSSH 9.0 (April 2022) made that hybrid the default key exchange.
• OpenSSH 9.9 (September 2024) added mlkem768x25519-sha256 and the standard name sntrup761x25519-sha512.
• OpenSSH 10.0 (April 2025) made mlkem768x25519-sha256 the default.
• OpenSSH 10.1 (6 October 2025) added the warning and the WarnWeakCrypto client option, enabled by default.

As of October 2026 the newest release is OpenSSH 10.5 from August 2026, and the client still prints the same three-line warning, according to the release notes and source code.

Why it started appearing on your machine

The warning is new client behaviour, so it usually appears after an update on your side rather than on the server. As of October 2026:

• Ubuntu 26.04 LTS ships OpenSSH 10.2p1, while 24.04 LTS remains on 9.6p1, according to Launchpad.
• Homebrew and Arch Linux package OpenSSH 10.5p1.
• Git for Windows has bundled OpenSSH 10.2 since version 2.51.1 (October 2025) and 10.5 since August 2026, per its release notes. By default Git uses that bundled ssh; the installer also offers an external OpenSSH option.
• The newest release of Microsoft's Win32-OpenSSH port is 10.0.0.0p2-Preview from October 2025, which predates the warning. On Windows the message therefore usually comes from Git for Windows or a WSL distribution rather than from Microsoft's own port.

One detail explains why two machines on the same version can behave differently. In the upstream code, the client prints the warning only when KexAlgorithms has not been set explicitly anywhere in its configuration: on the command line, in ~/.ssh/config or in a system-wide file (see sshconnect.c). If you or your distribution pinned a list, the message stays silent even when the negotiated algorithm is classical.

How to check which key exchange was negotiated

Run ssh in verbose mode and look for the kex line. GitHub suggests this form for its own servers; swap in your host:

ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'

For a Git remote, pass the flag through Git:

GIT_SSH_COMMAND="ssh -v" git ls-remote origin 2>&1 | grep 'kex: algorithm:'

Other commands that help:

• ssh -Q kex lists every key exchange your client supports.
• ssh -vv host prints a "peer server KEXINIT proposal" block; the KEX algorithms line inside it is the server's complete offer.
• ssh -G host | grep -i kexalgorithms shows the client list after all Host and Match blocks are applied.
• sudo sshd -T | grep -i kexalgorithms shows the effective list on an OpenSSH server.

If the result is mlkem768x25519-sha256, sntrup761x25519-sha512 or sntrup761x25519-sha512@openssh.com, the session is post-quantum. Anything else, such as curve25519-sha256 or diffie-hellman-group14-sha256, triggers the warning.

Fixing it on the server

Upgrade OpenSSH

According to OpenSSH, servers on 9.0 or later support sntrup761x25519-sha512, and servers on 9.9 or later also support mlkem768x25519-sha256. Version 8.9 already offers the @openssh.com form of sntrup761 by default, so a current client normally negotiates it. Servers running older releases, such as the 8.2p1 package in Ubuntu 20.04 LTS, offer none of these algorithms and will keep producing the warning until they are upgraded or replaced.

Look for a pinned KexAlgorithms list

If the version is recent enough and the warning persists, search for a KexAlgorithms line in /etc/ssh/sshd_config and in any files it includes. Hardening guides and compliance baselines sometimes pin a list of classical algorithms. Add the post-quantum names to that list, but only names that ssh -Q kex prints on that server: mlkem768x25519-sha256 and the suffix-free sntrup761x25519-sha512 exist only from 9.9 onward. On the server side the order of the list does not matter, because the client sets the preference. Then:

1. Validate the configuration with sudo sshd -t.
2. Reload the service while keeping an existing session open, so a mistake cannot lock you out.
3. Reconnect with ssh -v and confirm the kex line.

Network gear, appliances and other SSH stacks

Switches, routers, firewalls, storage arrays, managed SFTP services and embedded devices may run their own SSH implementation. Whether they can offer a hybrid key exchange depends on the vendor's firmware, so check its release notes for mlkem768x25519-sha256 or sntrup761x25519-sha512. Regulated environments add another limit: GitHub left its US data-residency region out of its rollout because only FIPS-approved cryptography may be used there, and sntrup761 is not FIPS-approved.

GitHub, GitLab, Bitbucket and Azure DevOps

GitHub announced in September 2025 that it would enable sntrup761x25519-sha512 on 17 September 2025 for github.com and for GitHub Enterprise Cloud with data residency, except the US region, and that GitHub Enterprise Server 3.19 would include it. A self-hosted GitHub Enterprise Server older than 3.19 is a likely source of the warning.

We checked the public SSH endpoints of the largest hosts on 5 October 2026 with OpenSSH 10.3 and the -vv method above:

• github.com and ssh.github.com on port 443 negotiated sntrup761x25519-sha512, so no warning.
• gitlab.com and bitbucket.org, including their altssh endpoints on port 443, negotiated mlkem768x25519-sha256.
• ssh.dev.azure.com (Azure DevOps Services) and the older vs-ssh.visualstudio.com endpoint offered only finite-field Diffie-Hellman methods (group14-sha256, group16-sha512, group18-sha512 and group-exchange-sha256), so every SSH fetch or push from OpenSSH 10.1 or later prints the warning.

If you see the message with github.com, gitlab.com or bitbucket.org, check what your remote really points at: a self-hosted instance or mirror, or a ProxyJump host, whose connection is a separate SSH session with its own check. For Azure DevOps there is nothing to fix on the client. You can switch the remote to HTTPS, where the key exchange depends on the TLS libraries at both ends, or mute the warning for that host.

Silencing the warning for one host

OpenSSH recommends disabling the warning selectively rather than everywhere. In ~/.ssh/config:

Match host ssh.dev.azure.com,vs-ssh.visualstudio.com
    WarnWeakCrypto no-pq-kex

The no-pq-kex value turns off only this check. WarnWeakCrypto no turns off every weak-crypto warning, including ones OpenSSH says the option may control in future releases, so it is a poor default. For a single command use -o WarnWeakCrypto=no-pq-kex, which also works inside GIT_SSH_COMMAND.

Clients older than 10.1 do not recognise WarnWeakCrypto and stop with a "Bad configuration option" error. If one config file is shared across machines, put IgnoreUnknown WarnWeakCrypto near the top, before the option first appears. Running ssh -q or setting LogLevel ERROR also hides the warning, but it hides other informational messages as well.

Post-quantum key exchange is one of several cryptographic changes reaching operations teams in 2026; shorter TLS certificate lifetimes are another. Our security and DevOps tooling sections follow both.

Frequently asked questions

Is "connection is not using a post-quantum key exchange algorithm" an error?

No. It is an informational warning from OpenSSH 10.1 and later, and the connection, login and Git operation continue normally.

Why does git push show the post-quantum warning?

Git runs ssh for SSH remotes, so the warning appears whenever the Git server does not offer mlkem768x25519-sha256 or sntrup761x25519-sha512. As of October 2026 that applies to Azure DevOps Services and to older self-hosted servers, while github.com, gitlab.com and bitbucket.org negotiate a post-quantum algorithm.

How do I disable WarnWeakCrypto for one server?

Add a Match host block for that server to ~/.ssh/config with the line WarnWeakCrypto no-pq-kex. This keeps the warning active for every other host.

Which OpenSSH version supports mlkem768x25519-sha256?

OpenSSH 9.9, released in September 2024, added mlkem768x25519-sha256, and OpenSSH 10.0 made it the default key exchange in April 2025.

Does GitHub support post-quantum SSH?

Yes. GitHub scheduled sntrup761x25519-sha512 for 17 September 2025 on github.com and on GitHub Enterprise Cloud with data residency outside the US region, and said GitHub Enterprise Server 3.19 would include it. As of October 2026, github.com negotiates it with current OpenSSH clients.