Key Exchange Detection Mechanism Bug

[e2w0y9sxt]

When attempting to SFTP into a system with a high-security SSH configuration, the following error is displayed:

Error:	The first key-exchange algorithm supported by the server is ecdh-sha2-nistp384, which is no longer secure. Aborting connection.
Error:	Could not connect to server

The server's /etc/ssh/sshd_config file has the below configured:

KexAlgorithms sntrup761x25519-sha512,ecdh-sha2-nistp384
Ciphers aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com

nmap shows the following:

# nmap --script ssh2-enum-algos -sV -p 22 127.0.0.1
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-13 10:35 PST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00019s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u4 (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms: (3)
|       sntrup761x25519-sha512
|       ecdh-sha2-nistp384
|       kex-strict-s-v00@openssh.com
|   server_host_key_algorithms: (4)
|       rsa-sha2-512
|       rsa-sha2-256
|       ecdsa-sha2-nistp384
|       ssh-ed25519
|   encryption_algorithms: (1)
|       aes256-gcm@openssh.com
|   mac_algorithms: (1)
|       hmac-sha2-512-etm@openssh.com
|   compression_algorithms: (1)
|_      none
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Both sntrup761x25519-sha512 and ecdh-sha2-nistp384 are clearly high-security KEX algorithms. Since the error doesn't even correctly state the first algorithm, it seems like there's a bug in the KEX detection/blocking code.

Please correct the weak KEX detection code to allow modern/secure KEX algorithms. Putty 0.83 is able to use both of these KEX algorithms without issue.

[Tim Kosse]

Could you please provide a public server address to test this configuration against?

[e2w0y9sxt]

Did a little more testing. I think I figured out the problem: sntrup761x25519-sha512 has not been implemented in FileZilla.

In Putty, I changed my "Default Settings" for KEX to "warn below here" any non-Post Quantum crypto. Those settings must be read by FileZilla, and "warn" translates to hard-fail. When I moved ECDH above "warn below here", FileZilla was able to connect.

I then reconfigured the server. First, using just p384 for KEX, FileZilla connects. Second, using just sntrup for KEX, FileZilla returns "Error: Could not connect to server"

Digging through Putty's change log, they implemented support for sntrup (aka NTRU) back in 0.78 (released 2022-10-29). OpenSSH implemented sntrup in 8.9/8.9p1 (2022-02-23). I'm guessing FileZilla is using a fork of Putty that's older than 0.78?

Let me know if you still want something to test against. Happy to spin up something in the cloud. Let me know if you want the KEX set to sntrup+p384 or just sntrup.

[e2w0y9sxt]

Did some more testing. Setting sshd's LogLevel to DEBUG2 made it clear that the issue is FileZilla has not implemented the sntrup KEX. Here is the relevant log entry showing what KEX algorithms FileZilla is proposing in an SSH handshake:

sshd[]: debug2: KEX algorithms: curve448-sha512,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1,ext-info-c,kex-strict-c-v00@openssh.com [preauth]

This is what Putty 0.83 is offering:

sshd[]: debug2: KEX algorithms: mlkem1024nistp384-sha384,mlkem768nistp256-sha256,mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve448-sha512,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group18-sha512,diffie-hellman-group17-sha512,diffie-hellman-group16-sha512,diffie-hellman-group15-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellm