SFTP rsa-sha2-256, rsa-sha2-512 key exchange issue

[norbertmm]

Compiled and linked curl to libssh2 current github master dev branch in order to get rsa-sha2-256 and rsa-sha2-512 server-key-exchange methods.

First SSH server connect works fine, server key gets saved to ssh local keyfile. Subsequent connects failing always because curl offers only "ssh-rsa", not "rsa-sha2-256" and "rsa-sha2-512" anymore, to server.

Could fix the issue with a little change to /lib/vssh/libssh2.c :
In ssh_force_knownhost_key_type()
static const char * const hostkey_method_ssh_rsa = "rsa-sha2-256,rsa-sha2-512,ssh-rsa";
instead of
static const char * const hostkey_method_ssh_rsa = "ssh-rsa";

This is the debug output when SFTP/SSH connect fails:
* Connected to 10.45.120.110 (10.45.120.110) port 22 (#0)
* Found host 10.45.120.110 in my_ssh_known_hosts.txt
* Set "ssh-rsa" as SSH hostkey type
* Failure establishing ssh session: -5, Unable to exchange encryption keys
* Closing connection 0

I think as soon a new libssh2 release is available (1.11.0), someone needs to address this issue in order to get rsa-sha2-256 and rsa-sha2-512. The old ssh-rsa (SHA1) is disabled within OpenSSH since version 8.8, 2021-09-26.

[bagder]

Could fix the issue with a little change to /lib/vssh/libssh2.c

The question is probably what the condition should be for using the updated string? Can we detect its presence in a better way than checking for the libssh2 version?

[norbertmm]

The string with methods is used in a call to libssh2_session_method_pref() which removes all unsupported methods.
First I thought it would be necessary to detect which method of the three to methods to use/prefer (by store key length or so) -- but it turned to not to be necessary. It just works magically.
If you have, for example, a rsa-sha2-512 key locally stored, you might call libssh2_session_method_pref("rsa-sha2-256") and it works. No idea why.

[bagder]

@norbertmm you up for writing a PR for this perhaps?

[norbertmm]

never done this ...

[bagder]

@norbertmm Is #10145 what you had in mind? I admit I have not really read up on the subtleties involved here.

[norbertmm]

@bagder Yes, that's right.
Perhaps it should be mentioned, that this fix is required to make CURLOPT_SSH_KNOWNHOSTS option work -- which is of course a good idea. Practically every SSH client is using such 'known-hosts file' mechanism. Otherwise you would have no server validation at all. CURLOPT_SSH_KNOWNHOSTS

[MonkeybreadSoftware]

What was the solution?

I got this error today with CURL 8.11.1 here, e.g.

URL: sftp://datahost01.duttenhofer.net/test

Host datahost01.duttenhofer.net:22 was resolved.
IPv6: (none)
IPv4: 82.212.249.16
  Trying 82.212.249.16:22...
Connected to datahost01.duttenhofer.net (82.212.249.16) port 22
Failure establishing ssh session: -5, Unable to exchange encryption keys
closing connection #0