AVC errors are logged in journal or in audit.log. ausearch -m AVC is helpfult too.

How can I check AVC errors?

Do you have some AVC errors? Does it work with SELinux in permissive?

Yes I have enabled SELinux.

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

Is your user somehow restricted (for example by SELinux)? Do you have some AVC errors? Does it work with SELinux in permissive?

Just iun case .. I have installed uid_wrapper

]$ rpm -ql uid_wrapper
/usr/lib/.build-id
/usr/lib/.build-id/de
/usr/lib/.build-id/de/92a25d0d0241dee4c96f47ebc0ec9b76c8154a
/usr/lib64/cmake/uid_wrapper
/usr/lib64/cmake/uid_wrapper/uid_wrapper-config-version.cmake
/usr/lib64/cmake/uid_wrapper/uid_wrapper-config.cmake
/usr/lib64/libuid_wrapper.so
/usr/lib64/libuid_wrapper.so.0
/usr/lib64/libuid_wrapper.so.0.0.8
/usr/lib64/pkgconfig/uid_wrapper.pc
/usr/share/man/man1/uid_wrapper.1.gz

I have the issue with libssh 0.9.2. I have tested with version 0.9.4 and it seems ok.

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.

From https://github.com/ashkulz/NppFTP/pull/292
Build with https://git.libssh.org/projects/libssh.git/snapshot/libssh-b1bbd20dfa8adc784c03fa74d8c81c30671d011b.tar.gz
-> https://travis-ci.org/github/ashkulz/NppFTP/builds/728703640

It's not an issue about libssh. In fact, we can only open 1 channel on the ssh connection. It's because of the software: Wallix bastion. Thanks for the help!

Some server logs might be helpful, but it looks like it is some non-standard ssh implementation so it might be hard.

I use exactly that functions: https://github.com/garnier-quentin/perl-libssh/blob/master/lib/Libssh/Sftp.pm#L69

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.

Application works fine with out invoking (any) ssh.lib functions, only it is an issue when I invoke ssh library. It works fine in windows-10 not on windows-7

Could you please specify which API you have to comment out to make it to work?

Thank you for confirming it fixed your issue. Glad to help.

Hi,
Thank you very much. Converting the key, I was able to login in the target system. This can be closed from my side.

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.

Well, the log shows
[2020/08/17 09:03:59.536616, 1] pki_private_key_from_base64: Unknown or invalid private key.

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.

Merged in master as c0b65cc

My requirement is as below:

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:

I guess that if in function "static int _ssh_finalize(unsigned destructor)"
this:

if (!destructor) {
    ssh_mutex_unlock(&ssh_init_mutex);
}
return 0;

would be replaced with this:

if (!destructor) {
    ssh_mutex_unlock(&ssh_init_mutex);
    if (!_ssh_initialized) {
        free(ssh_init_mutex);
        ssh_init_mutex = SSH_MUTEX_STATIC_INIT;
    }
}
return 0;

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

Server Administrator is on vacation for a week, once he is back I will share the information from the server logs. I thank you very much for your response.

Do you see some errors in the server logs?

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