- User Since
- Nov 7 2017, 9:55 AM (151 w, 1 d)
Fri, Sep 25
AVC errors are logged in journal or in audit.log. ausearch -m AVC is helpfult too.
Do you have some AVC errors? Does it work with SELinux in permissive?
Is your user somehow restricted (for example by SELinux)? Do you have some AVC errors? Does it work with SELinux in permissive?
Wed, Sep 23
Tue, Sep 22
We are not primarily C++ developers so the C++ wrapper is the minimal support we could provide. If you know how to do this in sensible way, submitting a pull request with the patch (ideally also with demonstration in examples) would be the simplest way how to get this in.
Thu, Sep 3
Some server logs might be helpful, but it looks like it is some non-standard ssh implementation so it might be hard.
Please, share what code did you use (what function calls). The server can be restrticted to SFTP only and if you try to open different channel, it can fail. To create sftp channel, you should use just sftp_new(), sftp_init() as in the examples/samplesftp.c.
Aug 20 2020
Thank you for confirming it fixed your issue. Glad to help.
Aug 17 2020
If I remember and read the code well, gcrypt does not have PEM parser (as it is mostly library for gnupg) so not all key formats are supported with gcrypt (we can do only the simple legacy PEM format, not the new PKCS8 PEM, which is default for some years in OpenSSL). OpenSSL provides sensible PEM parser which can parse quite much any key.
Aug 14 2020
Can you share verbose libssh log from your application attempting to log in? It should give you some idea what went wrong with this attempt.
Aug 13 2020
Merged in master as c0b65cc
Aug 12 2020
On windows yes, but it would fail everywhere else, where ssh_init_mutex is static mutex. Feel free to submit your suggested change in the gitlab -- it should run it through the CI to check if it works:
This looks like Windows-only issue. If the pthreads on Linux are used, the mutex is initialized statically, which is probably a reason why it does not pop up for us. It looks like windows locks do not support static initialization.
The ssh_channel_request_exec() executes separate command in separate ssh execute channel, which on the server results in starting a new shell, executing a command and exiting. Running separate commands this way does not work if you want the one affect the other. If you need this behavior, you should check how to open a shell, feed it with commands and read the output as described in the following chapter of the tutorial: https://api.libssh.org/stable/libssh_tutor_shell.html
Aug 5 2020
Do you see some errors in the server logs?
Jul 15 2020
No problem. I had to check how is this used in libssh myself as I never looked into this before.
Jul 11 2020
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.
Jul 8 2020
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.
Jul 7 2020
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 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 18 2020
Thank you for checking. It looks like I was too fast guessing the fix.
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.
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
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 21 2020
Merged as 4e4711d2 and friends.
Fixed in previously mentioned commits.
May 7 2020
FYI, this landed as e6aee24a
May 6 2020
Apr 24 2020
Apr 22 2020
It is still needed as the configuration parsing requires the hostname to evaluate conditional match blocks. But the new API ssh_options_set() should be used and documentation updated accordingly. The documentation should also mention that if it is not called, it is called automatically on connect.
Apr 21 2020
The previously mentioned commit disables the RSA-SHA1 and DSA algorithms by default.
Apr 20 2020
Apr 16 2020
AFAIK this was already addressed by using ssh -Q to query openssh supported algorithms and we have ubuntu 18.04 in CI to prevent similar issues in future.
Looks like the CI is running VS2017, which has still openssl 1.0.2. Would be nice to run against something supported.
This sounds like an issue discussed in . Can you check if it still happens with the current master + proposed fixes?
This has changed recently in master with commit 742d81ec. Can you check if you can still reproduce the issue with the referenced commit/master/
I believe this is fixed in current versions. If not, please reopen.
AFAIK, this was fixed with T194. Can you recheck if you can still reproduce the issue with latest release/master?
The example is missing the includes as mentioned in T225:
Some backtrace of the crash would be useful.
Apr 15 2020
Apr 14 2020
Seems like the linked multipass issue is fixed now. I am wondering why it was done by the change of the SSH_OPTIONS_SSH_DIR instead of SSH_OPTIONS_PROCESS_CONFIG which would prevent configuration parsing altogether.
Apr 9 2020
Can you submit the merge request on gitlab, where we can see results of the CI run?
Thank you for the report. You are right, this does not look like covered by any existing test case. The only one covered is the blocking mode in tests/client/torture_sftp_read.c. Contributions are always welcomed.
Can you check the following commit solves your problems:
Feb 18 2020
The above commits from @simonsj fixed this issue.
Feb 13 2020
Thank you for confirmation that this combination works. But lets clarify what you do -- you are sending every X minutes the ignore or keepalive messages to keep the channel open, but even though you are getting disconnects after 30 minutes. I do not think this is anything in libssh. What are you running in the channels? Port forwarding? Some long-running commands transmitting or not transmitting data? Shells? How does this disconnect look like? Could it be the default value of $TMOUT in bash? Or something on the network layer terminating long-running connections?
Feb 11 2020
I am sorry for a delay.
Jan 29 2020
the ssh_send_keepalive() does really only the sending. But the return value is ignored since 59ada799. But if the sending failed, the session state should be modified to reflect this if I am right. The response is handled as any other message in ssh_handle_packets() if I am right. The response is anyway SSH_MSG_REQUEST_FAILURE.
Jan 28 2020
Please, check the RFC 4253 describing this message: https://tools.ietf.org/html/rfc4253#section-11.2
Jan 27 2020
Jan 23 2020
One other possibility that could work would be TCPKeepAlive configuration option (from OpenSSH), which could handle this on TCP level (but might not work on all the networks configurations). So still, the first advice holds.
This is not implemented inside of libssh now, but it can be simply implemented by your application that will send some data in your defined time intervals, for example using ssh_send_ignore().