Hi Eric,
Thanks for these additional logs, I think we found the issue!
libssh_at_bentleyemail.net wrote:
> # ssh -v -oCiphers=aes128-ctr -oMACs=hmac-sha2-256 192.168.1.123
> OpenSSH_8.5p1, OpenSSL 1.1.1k 25 Mar 2021
..
> debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
> debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
Now the OpenSSH client uses the same cipher and MAC as libssh2 did,
and then reports:
> ssh_dispatch_run_fatal: Connection to 192.168.1.123 port 22: error in libcrypto
This error message from the client shows that the problem is actually
with libcrypto (OpenSSL) and not with libssh2. I guess that the
embedded build of OpenSSL disables a feature required for hmac-sha2-256.
It is a different - but also relevant! - problem that libssh2 behaves
the way it does in this case. I don't know if it fails to check
availability or whether it just needs to provide an error message
which makes sense. Either way it's sloppy and we should fix that.
But to answer your original question, for your connection to succeed
with curl/libssh2 and with OpenSSH using same cipher and MAC you'll
have to work on how OpenSSL is being built.
Once OpenSSH works with those options libssh2 will likely work as well.
//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2021-05-20