When login via SSH into a NS8, I am now greeted with:
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to “store now, decrypt later” attacks.
** The server may need to be upgraded. See OpenSSH: Post-Quantum Cryptography
I am using an macbook, what did I do to deserve this? A new McShell warning/advise since the last Tahoe 26.3 update? Is it important?
I’ll try it on the Mac mini by connecting to NethSecurity and let you know if I get the same result.
I’d have to install nethserver on the PC of the neighbor who’s helping me with the virtual machine.
I had a chaotic day looking for jobs and I’m back with the kids who were at school and I’m walking here.
Ok, I think I got it:
My MacOS client (Tahoe 26.3) has:
OpenSSH_10.2p1, LibreSSL 3.3.6
Nethserver 8 (all updated up to end of february 2026):
OpenSSH_8.7p1, OpenSSL 3.5.1 1 Jul 2025
and according the OpenSSH FAQ:
I received a warning from ssh that directed me to this page. What should I do?
As mentioned above, OpenSSH 10.1 started warning users when connections use cryptography that is not safe against quantum computers. If you received such a warning, it means that the server you connected to did not offer one of the two post-quantum key agreement algorithms that are being standardised for the SSH protocol: mlkem768x25519-sha256 and sntrup761x25519-sha512
The ideal solution is to update the server to use an SSH implementation that supports at least one of these. OpenSSH versions 9.0 and greater support sntrup761x25519-sha512 and versions 9.9 and greater support mlkem768x25519-sha256. If your server is already running one of these versions, then check whether the KexAlgorithms option has disabled their use.
Fixing the server side may be preferred over ‘silencing’ the warning message.
How about:
ssh -V
NethSecurity returned the dropbear response
In a local terminal shell on your Mac mini? (So not the NethSecurity shell)
The second image is of the Mac; it’s the same as yours.
Ah yes, so as indicated by the warning and FAQ, only OpenSSH issues the warning. But what to do, or who needs to do what?
I can’t reproduce the warning on my macbook. I updated to 26.3 and got OpenSSH_10.2p1 but I don’t get the warning when connecting to a Rocky NS8 or to other servers.
Is there something else to do to get that warning?
me neither.
On NS8-Server
~# ssh -V
OpenSSH_9.2p1 Debian-2+deb12u7, OpenSSL 3.0.18 30 Sep 2025
I think it’s ok as there’s no warning when OpenSSH 9.0+ (which supports the pq kex algo) is installed which seems the case for Debian.
On Rocky, OpenSSH 8.7 is installed and there should be a warning.
So Rocky users simply wait until the SSH server version is upgraded to 10.x.x?
I assume that wouldn’t happen until some future release of Rocky (e.g., Rocky 10). RHEL, and thus CentOS, would stay on the same major/minor versions of software throughout a release’s lifecycle.
So the FAQ advise comes into play when annoyed by the constant nag on current Rocky:
If you are unable to update the server and/or you prefer to accept the risk of continuing to use quantum-unsafe cryptography then the warning may be silenced via the WarnWeakCrypto option in ssh_config(5). We recommend doing this selectively, for example:
Match host unsafe.example.com WarnWeakCrypto no
It seems possible to get some of the pq features in Rocky 9 but not for OpenSSH (I didn’t test it)
From Prepare for a post-quantum future with RHEL 9.7 :
To get started with post-quantum OpenSSH, consider upgrading to RHEL 10.
To enable the pq policy, see Chapter 3. Using system-wide cryptographic policies | Security hardening | Red Hat Enterprise Linux | 9 | Red Hat Documentation
Post-Quantum Cryptography in RHEL 10 — Summary
Why it matters now
Cryptographically relevant quantum computers don’t exist yet, but the “harvest now, decrypt later” threat is already real: state-level actors are likely storing encrypted traffic today to decrypt it once quantum computers become available. The migration to post-quantum cryptography (PQC) must start now, even though the full transition will take years.
So how to proceed if one wants to be protected as much as possible on NS8 please?
Anybody have some time/knowledge to prep a “simple how-to”? For it seesm to be pretty important in light of the article shared by @stephdl “harvest now, decrypt later”.
I have 2 ideas/approaches to fix the issue.
Update base package.
The raven repo has a newer version of openssh.
It’s also possible to install OpenSSH and replace the base package but it needs to be updated manually.
Use an OpenSSH container.
Linuxserver.io provides an OpenSSH container image. It could be used as jumphost to the local OpenSSH.
I’m going to test and report…
I would opt for option 2, an OpenSSH container.