me@host operations-puppet $ git grep curve25519-sha256@libssh.org
modules/gitlab/manifests/ssh.pp:    Array[String]              $kex_algorithms       = ['curve25519-sha256@libssh.org', 'diffie-hellman-group-exchange-sha256'],
modules/ssh/templates/sshd_config.erb:KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

So potentially this affects not just GitLab but also production SSH…

In T407557#11282964, @LucasWerkmeister wrote:

So potentially this affects not just GitLab but also production SSH…

Sure does:

$ ssh deployment.eqiad.wmnet
** 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
Linux deploy2002 5.10.0-36-amd64 #1 SMP Debian 5.10.244-1 (2025-09-29) x86_64
Debian GNU/Linux 11 (bullseye)
deploy2002 is a Deployment server for all Wikimedia services (deployment_server::kubernetes)
…

So I guess let’s repurpose this task a bit. Not sure what the right tag for production SSH config is, I’ll just make a guess…

In T407557#11282964, @LucasWerkmeister wrote:

me@host operations-puppet $ git grep curve25519-sha256@libssh.org
modules/gitlab/manifests/ssh.pp:    Array[String]              $kex_algorithms       = ['curve25519-sha256@libssh.org', 'diffie-hellman-group-exchange-sha256'],
modules/ssh/templates/sshd_config.erb:KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Though this was apparently based on an older puppet checkout I had – the second line was in fact removed by @jhathaway (CR by @MoritzMuehlenhoff) last week. I don’t know why I’m still seeing the warning for production SSH then o_O

(Wrong Mortiz)

Assuming gitlab ssh config needs changing, this needs attention of collaboration-services team. Production seems to be handled already.

In T407557#11284684, @Ladsgroup wrote:

Production seems to be handled already.

No it isn’t, as shown in T407557#11284514. (Though I don’t understand why the warning is still shown.)

Also affects Gerrit:

$ git fetch
** 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

deploy2002 is running bullseye, which has ssh 1:8.4p1-5+deb11u5, so it does not have any of the post quantum algorithms that were first added in 9.0.

gerrit1003 is also bullseye, but the issue is gerrit itself, rather than the openssh-server. I think gerrit uses, https://github.com/apache/mina-sshd, I'm not sure whether it supports any of the post quantum algorithms yet.

In T407557#11285825, @jhathaway wrote:

gerrit1003 is also bullseye, but the issue is gerrit itself, rather than the openssh-server. I think gerrit uses, https://github.com/apache/mina-sshd, I'm not sure whether it supports any of the post quantum algorithms yet.

According to #803 it gained support for mlkem768x25519-sha256 at some point, though I think that might not have made it into a proper release yet (only the upcoming 3.0.0-M2 if I’m not mistaken). Somewhat earlier, #498 added and #528 fixed sntrup761x25519-sha512; this was seemingly first released in sshd-2.13.2.

In T407557#11285825, @jhathaway wrote:

deploy2002 is running bullseye, which has ssh 1:8.4p1-5+deb11u5, so it does not have any of the post quantum algorithms that were first added in 9.0.

gerrit1003 is also bullseye, but the issue is gerrit itself, rather than the openssh-server. I think gerrit uses, https://github.com/apache/mina-sshd, I'm not sure whether it supports any of the post quantum algorithms yet.

https://github.com/apache/mina-sshd/commit/4f2ccf885292adde1d3a0d5f9abd9fb513b07688 I think added support for post quantum algorithms I think? Which gerrit 3.11 uses (uses version 2.14 which has that commit).

debug1: Remote protocol version 2.0, remote software version GerritCodeReview_3.10.6 (APACHE-SSHD-2.12.0)
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,curve448-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group18-sha512,diffie-hellman-group17-sha512,diffie-hellman-group16-sha512,diffie-hellman-group15-sha512,diffie-hellman-group14-sha256,ext-info-s,kex-strict-s-v00@openssh.com

our version does not offer support for, sntrup761x25519-sha512, or mlkem768x25519-sha256

Summarizing what was said above, there are two parts to this request:

• Host-deployed OpenSSH version, which should be resolved with the upgrade to Bookworm and above
• Gerrit mina-ssh version, which should be resolved with the upgrade of Gerrit to 3.11 (we're at 3.10 now) - FYI @hashar

In T407557#11284684, @Ladsgroup wrote:

Assuming gitlab ssh config needs changing, this needs attention of collaboration-services team. Production seems to be handled already.

Thank you for tagging collaboration-services ! Regarding GitLab, we have a dedicated Puppet module which installs a second sshd interdependent from the GitLab omnibus package. So we should be able to add other algorithms pretty easily, the hosts are also on bookworm already.

It's not fully clear to me which of the additional algorithm should be supported. But I can add it to GitLab as soon as we agreed on a algorithm.

For Gerrit, it requires a change to an upstream library (Apache MINA SSHD). I have filed the sub task T407844 for it. Meanwhile the warning can be disabled using:

Host gerrit.wikimedia.org
    WarnWeakCrypto=no-pq-kex

Gonna quickly note here that Wikimedia Cloud VPS is apparently not affected (at least when SSHing to a Bookworm VM – supports sntrup761x25519-sha512), and neither is Toolforge (Trixie bastion additionally supports mlkem768x25519-sha256).