Thank you for testing the latest change. The throughput looks good now. Closing the issue.
Mon, Nov 25
Thu, Nov 21
Congratulation to the issue #200 :)
You are probably right. I was not able to reproduce it locally even from repetitive runs in the same container image with the same code.
Thanks. There are just a few nits I pointed out in the comments. The changes generally look good to me now and ready to merge (after the freeze -- see the email).
Wed, Nov 20
Update: Your branch passes for me locally in container with OpenSSL now with last fix. But the commits still need some love before we can merge them. Will you have some time to touch that in coming days so we can add the ubuntu targets?
@aris I added the Ubuntu CI image, where I can successfully build libssh now:
Mon, Nov 11
This should be addressed in the latest release 0.9.2. Not sure why it was not auto-closed with the commit referenced above.
Nov 4 2019
@ansasaki This looks directly related to the ed25519 support you modified to use OpenSSL. Can you check what might have gone wrong?
@aris your commits are missing Sign-off. I added my review. I also see many failed pkd tests in the last CI run with Fedora. Are they related to your changes?
Nov 1 2019
Sounds like an issue with the ed25519 keys then. Can you open a separate issue, since this is indeed different one than the reported above (RSA keys). Clarifying what openssl version are you using and whether it has enable support for ED25519 keys would help.
Oct 31 2019
This should be handled by the code in kex.c. It correctly sets the session->extensions bit field based on what is supported by the client in the key exchange. The problem here is that it informs only about the support of these extensions, but not about their priority and whether to prefer the SHA1 hash or the SHA2 ones. There is already attempt to detect whether the SHA256 or SHA519 was preferred, but this particular use case is not handled (what is the point in signaling that I know stronger algorithms, but prefer the SHA1?).
Oct 25 2019
Oct 10 2019
Theory sounds right. Were you able to confirm this theory and fix your code to handle empty responses?
Oct 1 2019
Sep 25 2019
I think this was addressed by https://gitlab.com/libssh/libssh-mirror/merge_requests/63 for OpenSSL.
I think we should update the documentation so it is clear that the structure needs to be valid as long as the channel/session is valid.
Sep 24 2019
Sep 20 2019
Can you clarify on what platform you are experiencing these issues?
Thank you for the bug report. Indeed, the handling of the modulus and generator is wrong. These bignums are copied in the ssh_dh_set_parameters() into the keypair structures (when using openssl backend), but the calling function did not free them as expected. Also the handling of errors was wrong in case of some failures checking them.
Sep 19 2019
The tests/pkd/pkd_util.c already parses the openssh version so it can be used with a bit of refactoring. Or you can adjust the tests/CMakeLists.txt to expose the already-collected versions also the pkd tests and allow these alogirhtms only on the newer openssh.
Sep 18 2019
Thank you for testing. Whether and where to list your perl bindings in the main page, that is more up to @asn, but I do not think it should be a problem.
Sep 17 2019
Thank you for the reproducer. I can confirm and reproduce with your attached code. This is the backtrace:
#0 0x00007f8df8576c10 in __poll_nocancel () from /lib64/libc.so.6 #1 0x00007f8df14d58c0 in ssh_poll () from /lib64/libssh.so.4 #2 0x00007f8df14d6033 in ssh_poll_ctx_dopoll () from /lib64/libssh.so.4 #3 0x00007f8df14d798c in ssh_handle_packets () from /lib64/libssh.so.4 #4 0x00007f8df14d7a93 in ssh_handle_packets_termination () from /lib64/libssh.so.4 #5 0x00007f8df14ae889 in channel_request () from /lib64/libssh.so.4 #6 0x00007f8df14afa6b in ssh_channel_request_exec () from /lib64/libssh.so.4 #7 0x00007f8df1740837 in XS_Libssh__Session_ssh_channel_request_exec () from /usr/lib64/perl5/vendor_perl/auto/Libssh/Session/Session.so #8 0x00007f8df989c41f in Perl_pp_entersub () from /usr/lib64/perl5/CORE/libperl.so #9 0x00007f8df9894b96 in Perl_runops_standard () from /usr/lib64/perl5/CORE/libperl.so #10 0x00007f8df9831985 in perl_run () from /usr/lib64/perl5/CORE/libperl.so #11 0x0000000000400ce9 in main ()
In the server, log the event of failed session opening is visible here:
Sep 17 14:59:42 jjelen-rhel-7.3 sshd: debug1: channel 10: new [server-session] Sep 17 14:59:42 jjelen-rhel-7.3 sshd: debug1: session_open: channel 10 Sep 17 14:59:42 jjelen-rhel-7.3 sshd: error: no more sessions Sep 17 14:59:42 jjelen-rhel-7.3 sshd: debug1: session open failed, free channel 10 Sep 17 14:59:42 jjelen-rhel-7.3 sshd: debug1: channel 10: free: server-session, nchannels 11 Sep 17 14:59:42 jjelen-rhel-7.3 sshd: debug3: channel 10: status: The following connections are open:\r\n ... Sep 17 14:59:42 jjelen-rhel-7.3 sshd: debug1: server_input_channel_open: failure session
Sep 16 2019
I implemented the match exec. Can you try if it works for you as expected in your use case? There are several commits adjusting the tests and as well as I had to implement new token parsing function, but my basic tests looked good. This code also does not work on windows since I am not Windows developer, but if interested, I believe there will be somebody who could implement that.
The original issue should be resolved in master now.
Aris, can you open a new bug for this, ideally with more debug information as proposed by @ansasaki?
Sep 13 2019
Can you check the following patch if t addresses the issue for you?
I am getting exactly the same result as the OP when I remove the /usr/bin/nc, which is used in the respective failing test so I assume that this is the issue, but the error should be more properly reported and the test probably skipped in case the netcat is not in place. I will submit a patch.
Thank you for having a look into that. In that case, I am wondering why it did work for me and for the CI we run, but I think most of that is on Fedora, which might be a difference. Can you check whether the netcat (nc) is installed in your system?
I just tested the ssh-client from examples, which is using channel_open with sshd configured with MaxSessions 0 and it is correctly failing and not hanging for me. Can you test with current libssh master or 0.9 and provide more ellaborate reproducer?
The file doc/sftp.dox contains the following information (not sure whether it is rendered somewhere on the web):
This should be addressed by using the new API even inside of the deprecated functions without the change of functionality. Can you try the following patch?
The modification of the libssh.h is breaking other applications (for example the applications in example directory) using this header file not defining HAVE_INTTYPES_H and HAVE_UNISTD_H themselves. Can you clarify what problem are you solving by this and on what system you do not have these header files?
Did you try the latest libssh 0.9 . Not sure what went wrong with the old version, but the windows builds are part of CI and they should work in recent version
Aug 20 2019
I think the multi-criteria matches are generally supported, but I agree that they are not tested and that should be fixed.
Aug 8 2019
Aug 7 2019
Just for the record, the OpenSSH position to implementing this key exchange algorithm:
Aug 1 2019
Jul 30 2019
Jul 25 2019
You are probably right, Can you try with the following patch:
Jun 27 2019
Jun 26 2019
The current version should have improved memory handling. Can you retest whether the speed is better now?
Jun 24 2019
Thank you for the clarification and updated reproducer. I can reproduce it with the latest version installed by the package manager in Debian (0.8.7), but I can not reproduce it when I build the example against current master. I can not reproduce it even if I manually checkout the version 0.8.7 from git.
This is already available in master (e989c4afffa154d92fe8c4ae1716ecc6bb4c2fd5) and will be in 0.9. Unfortunately, this did not got updated in Fedora as we updated the default configuration file so I would propose to wait few days for the updated libssh or fill a fedora bug.