Here the debug. It seems OpenSSH has the same issue.
Needs Triage (15)
Wed, Jul 8
Thanks for confirmation. Even though you can not change the server settings, there might be something useful in the logs pointing out what is the issue. It could be bug in srtSSHServer implementation or libssh implementation of the new diffie-hellman-group18-sha512 so it is worth investigating.
Tue, Jul 7
With following in ssh_config for my host, it's working:
Okay. So i cannot change the server (update or settings). I will try to force 'diffie-hellman-group14-sha1'. Thanks!
This is an issue of key exchange, not ciphres. The original trace is using probably diffie-hellman-group14-sha1 and the new one diffie-hellman-group18-sha512. The error invalid DH value comes from the server so I would suggest continuing some investigation there, figuring out what it does not like on the provided DH value.
Thu, Jul 2
@Jakuje thanks for your reply and the details, the build system doesn't really make clear than nacl is not needed when building with openssl. In regard of your explanation I don't think adding libsodium as yet another alternative is really needed so feel free to close the request. I've submitted a request to Debian now also to stop pulling nacl in their build
Wed, Jul 1
Tue, Jun 30
I do not think nacl is used for anything at this moment when libssh is built against current openssl, which already supports X25519 curve for all we need. At least in Fedora, nacl is not listed as dependency of libssh at all.
Mon, Jun 29
Thu, Jun 25
Sorry for delay in response.
Mentioned commit fixes problem.
Wed, Jun 24
Tue, Jun 23
Mon, Jun 22
Fri, Jun 19
We tried to keep those wildcards working when we introduced the fix for CVE-2019-14889, but we couldn't.
Thu, Jun 18
Could you please check if the change I proposed in https://gitlab.com/libssh/libssh-mirror/-/merge_requests/122 fixes the issue for you?
Thank you for checking. It looks like I was too fast guessing the fix.
Tue, Jun 16
I have tested the same code on master (245ad744b5ab0582fef7cf3905a717b791d7e08b commit). ssh_channel_read still return -1 sometimes.
I have enabled ssh debug and it looks like some timing problem. There is log part:
Sun, Jun 14
Wed, Jun 10
Sounds like a mitigation to some of the security issues fixed in 0.9.3. See the announcement message for more details:
Jun 9 2020
Playing a bit more with that, it looks like a version 8.7.0 returns SSH_AUTH_AGAIN from ssh_userauth_none(), even though it is in blocking mode. It is certainly not correct, but better than not returning at all. But only after a timeout, which it spends in busy-loop wait.
Jun 8 2020
I am able to reproduce this locally. The server sends SSH_MSG_DISCONNECT to the client, but in the ssh_userauth_get_response(), this message is not accepted to terminate waiting for answer from server in ssh_auth_response_termination() so it hangs forever in the poll -- I think this is a bug in poll implementation, which should stop waiting after receiving disconnect.