Error message is shown in the picture below.

We are currently trying to get x2go running with a teleport (https://gravitational.com/teleport) based bastion host. Teleport issues host as well as user certificates, which currently blocks x2go usage through the bastion host.

No problem. I had to check how is this used in libssh myself as I never looked into this before.

We test interoperability with OpenSSH so our implementation is compatible with OpenSSH one. So either we both are wrong or the srtSSHServer_11.00 is wrong. I would recommend you either check the server side for more logs or errors and/or contact the vendor/support of the server that you have this issue. It should be trivial for them to reproduce/debug the issue as libssh and openssh are opensource and they can reliably reproduce the issue. From just this log, we can hardly guess what the blackbox server does not like on this key exchange method implementation.

Here the debug. It seems OpenSSH has the same issue.

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.

With following in ssh_config for my host, it's working:
Host 192.168.xxx.xxx

KexAlgorithms diffie-hellman-group1-sha1

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.

@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

I agree.

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.

Sorry for delay in response.
Mentioned commit fixes problem.

We tried to keep those wildcards working when we introduced the fix for CVE-2019-14889, but we couldn't.

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.

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:

Sounds like a mitigation to some of the security issues fixed in 0.9.3. See the announcement message for more details:

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.

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.

added several check to the code.

Right. It affects only 0.9.x versions. The above commit mentions which revision introduced this issue. The commit is already backported in the stable-0.9 branch so it will be in the next 0.9.5 release

It is fixed in the master.

Could it be a duplicate of an issue described and fixed in this commit [1]? It was also discussed in mailing list recently. Does it work with current master?

Merged as 4e4711d2 and friends.

Fixed in previously mentioned commits.

Fixed in https://gitlab.com/libssh/libssh-mirror/-/merge_requests/118

FYI, this landed as e6aee24a