Hi Eric, Thanks for these additional logs, I think we found the issue!
lib...@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
