Error message is shown in the picture below.
Error message is shown in the picture below.
Thu, Jul 23
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.
Thu, Jul 16
Wed, Jul 15
No problem. I had to check how is this used in libssh myself as I never looked into this before.
Tue, Jul 14
Sat, Jul 11
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.
Thu, Jul 9
Here the debug. It seems OpenSSH has the same issue.
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.
Jul 2 2020
@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
Jul 1 2020
Jun 30 2020
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.
Jun 29 2020
Jun 25 2020
Sorry for delay in response.
Mentioned commit fixes problem.
Jun 24 2020
Jun 23 2020
Jun 22 2020
Jun 19 2020
We tried to keep those wildcards working when we introduced the fix for CVE-2019-14889, but we couldn't.
Jun 18 2020
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.
Jun 16 2020
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:
Jun 14 2020
Jun 10 2020
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.
Jun 4 2020
added several check to the code.
Jun 3 2020
May 25 2020
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 ? It was also discussed in mailing list recently. Does it work with current master?
May 22 2020
May 21 2020
Merged as 4e4711d2 and friends.
Fixed in previously mentioned commits.