Not sure if this is just coincidence or somehow related to me having just swapped in a larger external USB drive for my Diet-Pi (Pi4 B) based Plex server setup… but I’m getting this note when I SSH in from my Mac:
** 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 ``https://openssh.com/pq.html
I can proceed with my password despite the warning, and all is fine. My server and Pi and Plex operate fine. That said, I should give this note some attention.
So, can someone enlighten me how specifically my server might need to be upgraded? My DietPi install is already up to date.
The openssh.com link gives me this:
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-sha512and 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.
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
That explains a bit, but I still need some guidance on whether I really need to upgrade something, set this to ignore… or if this is something new that will be handled in due time by a DietPi update.
Any insight would be helpful. Thanks 
I don’t think you need to do anything here at the moment. The risk of encountering an attacker with quantum computers is certainly still manageable at the moment. In addition, you will probably not have made your SSH server accessible to the internet. This means that no one should be able to access it.
Got it, thanks. Have a good weekend.
Do you override the default KexAlgorithms in /etc/ssh/sshd_config or /etc/ssh/sshd_config.d? These key exchange algorithms are enabled by default on OpenSSH versions which support it, one of them since Bookworm, both since Trixie:
So this warning should not show up on any supported Debian version.
No I wouldn’t class myself as advanced enough to really mess with a lot of defaults – certainly not without some good guidance.
That said, getting SSH working (and working some Plex-related tasks) did take some fussing that folks here chimed in on. That was a long time ago though.
I certainly haven’t changed anything recently – other than swap an external drive (which I can’t see being a factor at all). When I had a potential issue with the drive that I’ve now replaced… the Pi was shut down and sat on a shelf until I started up with the new drive yesterday. There were no warnings prior to all this.
Happy to pass along an output or file that may be related, if you’re curious. Just let me know how to get to what might be useful. Otherwise I’ll just ignore the warning as Joulinar suggested, and get a quantum-proof tinfoil hat to protect myself for now
Thanks for speaking up - have a good weekend.
@Joulinar I should ask one more question on this: is there a way for me to remove this post-quantum key warning message, so I don’t have to see it every time? I recall seeing a different warning in the past and you had the option to ignore / turn it off, but there’s no such option here.
Please assure that this setting is really not overridden. Any change to a config file prevents dpkg from replacing it automatically, no matter how long ago it was done:
grep -r KexAlgorithms /etc/ssh
And which Debian version are you using?
cat /etc/os-release
sshd -V
Debian GNU/Linux 12 (bookworm)
Just noticed this actually “Debian 13 Trixie has been released. Learn how to upgrade”
And that grep command returns nothing: grep: /etc/ssh: No such file or directory
Ohh, so you use Dropbear. Okay so the OpenSSH client throws this warning also when connecting to a non-OpenSSH server. The info page somehow seems to assume one was connected to OpenSSH.
Yeah, just checked, Dropbear on Bookworm does not yet support those algorithms, but Dropbear on Trixie does. Good or not: Dropbear has no transparent way of enabling/disabling these, so no chance to break with config edits or so 
.
So in that case, and anyway, makes sense to upgrade to Trixie: Debian 13 Trixie has been released – DietPi Blog
Follow the suggestion to create a backup, just in case, but the script is solid after 3/4 year of usage and polishing. If any issues appear, we are here to help.
Thanks Michal, I will make a backup of my card and look at the upgrade next week. If those instructions are not clear to or I have a question along the way, I’ll get back to you
Just backed up my SD card to my Mac, then did the Trixie upgrade via SSH using your command.
No problems along the way.
The backup phase took exactly 30 mins (my 64gb card had about 25gb on it), then I got a log from that phase. The upgrade phase then took about 10 mins until the reboot notice.
I’m back up and running now. Will make sure Plex is working properly tonight, but on a quick first launch it seems fine.
Of note, as was suggested, there’s no more post-quantum warning on reboot.
Oh, and sudo apt autoremove found nothing to tidy up, and sudo apt autopurge also found nothing.
2 Likes
You mean that one that is triggered on first login after reboot after the Trixie upgrade? Surprising, but maybe one of the other steps implied an autoremoval already prior to the reboot.
Yeah there may have been an automatic round as part of the upgrade.
There were also a couple of suggestions along the way, however, to run those two things manually when the whole process was complete, so I did.