Curl 8.4 when using sftp servers, when negotiating the key and host key algorithms is truncating the names of the cipher algorithms.

[luispduarte-novobanco]

Hello, we are using libcurl or curl to connect to diferents sftp servers. And some of them are using ssh-dss host algorithm.
Curl when sending the client host algorithms is truncating the string and doesnt let know to the host all the supported algorithms. Is these is a bug?
If we could control the list of hosts or key algorithms we could short the list and not truncate the string but there is no option. The ciphers option only works for https and not sftp.
We can see the issue in the attachement when negotiating the algorithms. Curl returns the error "curl: (2) Failure establishing ssh session: -5, Unable to exchange encryption keys" and the server is returning the error "The SSH2 session has terminated with error. Reason: Error class: LocalSshDisconn, code: KeyExchangeFailed, message: FlowSshTransport: no mutually supported host key algorithm."
The list of hosts key algorithms that curl is sending are:

ecdsa-sha2-nistp256,
ecdsa-sha2-nistp384,
ecdsa-sha2-nistp521,
[email protected],
[email protected],
[email protected],
ssh-ed25519,
[email protected],
rsa-sha2-512,
rsa-sha2-256,
ssh-rsa,
[email protected]

Another question is why there are algorithms that ends with "@openssh.com" in the names?

Suported host algorithms:

Suported client algorithms (truncated):

[jzakrzewski]

I think the truncation is a Wireshark thing. IIRC there's a line length limit for the decoded frame display. It should, however, be possible to copy the whole thing and look at it in a text editor.

[luispduarte-novobanco]

I have made that, but the message is in reality truncated. The packet has a total length of 1252. All the bytes of the packet in attachement.
ssh_bytes.txt

[dfandrich]

Looking at your message, I'm guessing that you're using the libssh back-end. What do you refer to when you say "all the supported algorithms"? Are you talking about all the algorithms support by libssh? Or some other set? Do you see more algorithms sent using another libssh-using application, or how else do you know there are more? The algorithms ending in @openssh.com are the ones that are not standardized, but are created by one ssh client/server, OpenSSH in this case. Other clients/servers are free to use them to interoperate, of course, but the IANA doesn't track them.

[luispduarte-novobanco]

What I can see is in the key exhange field is truncate do 331 byte. The dump of the string in that field is in attachment.
key exchange_algoritms.txt
Tha last algoritm in the list is "ext-info-c" witch is truncated.
If you want a tcpdump capture is in attachment. These capture is from other server but you can see the key init exchange algoritms are truncated.
dump.zip

[bagder]

You still haven't mentioned with SSH library you use, but the details you're looking at is managed by the SSH library and it seems very unlikely that curl does or even can affect the key exchange field in the way you describe.

[dfandrich]

I think @jzakrzewski is right—the raw hex data does not appear to be truncated. And, for reference, the dump shows that libssh2 1.11.0 is in use. Why do you think "ext-info-c" is truncated? It's defined in RFC8308.

[luispduarte-novobanco]

thank you for the update.
All these resumes to these version of curl not compatible to the ssh-dss algoritm available from these SFTP server. Is there a way to enable it in the client?
best regards.

[bagder]

Are you asking what is supported or not? Since your curl is built to use libssh2, all the SSH and SFTP level communication is managed by that library so for detailed information about what it supports or not, it might be better to take it there. @libssh2