FYI, as a workaround, you can use ProxyCommand='ncat -vvv --proxy <proxy server:port> --proxy-type socks5 %h %p' -o'User <user> 2>/dev/null', which drops the stderr. But indeed, this is something to fix in libssh.

This was resolved recently by 4a67c191188601c8d98ec73b9d53ce8a2b6c6cf8 which implemented EtM modes of the MACs in libssh and which is available in latest libssh release.

Can you provide example of such key? Do you mean private keys in PEM format or in OpenSSH format? Or public keys?

I think this got resolved over the time and the PEM files are readable including the inline comments (probably because of the removal of the SSH1 protocol, which had special conditions for the old RSA1 keys).

Please, check the following commits in the master-fix branch:

Do you have a minimal reproducer that demonstrates this issue? The following parts do not look correct:

[2019/02/21 16:35:31.187831, 3] callback_receive_banner: ssh_protocol_version_exchange: Ncat: Version 7.70 ( https://nmap.org/ncat )

a bit later is what should be coming -- the SSH identification banner:

[2019/02/21 16:40:54.932576, 3] callback_receive_banner: ssh_protocol_version_exchange: libnsock nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 10 [peer unspecified] (33 bytes): SSH-2.0-1.36_sshlib GlobalSCAPE..`

I am afraid that the ncat dumps some additional data to stderr, which is unintentionally picked up by the libssh. This is caused by the code in the src/socket.c:815, where both stdout and stderr is redirected to libssh

dup2(out,1);
dup2(out,2);

You ca try to drop the second line above, which should let the stderr to be mixed up with the libssh stderr or dropped (not sure from top of my head), but it should let you move on.

The same thing works for me with the current openssh-portable master that I just built in my Fedora VM. Could this be somehow related to the Ubuntu toolchains or packages, rather than to the 32 bits itsef?

I tried also the 0.8.7 branch as reported in the previous comment, but with the same result. Could it be an issue in valgrind or some other part of the toolchain?

I just installed Fedora 27 i386 image (I was not successful with installing anything newer since it is secondary architecture for several releases and receives close to none testing) and current libssh master and I can not reproduce your issue.

Is this using musl libc?

Should be fixed by 1f43b52117fc97eef95e3627517cadb531b2b43e

I just adjusted the documentation comment a bit, and removed the invalid warning from ssh_threads_get_pthread()

Sounds good to me.

If I read correctly the manual page for ssh_config, your example is invalid:

I will push that soon, thanks for your contribution!

Looks fine for me, thanks for your contribution!

My guess would be that the test requires HAVE_GLOB_GL_FLAGS_MEMBER but musl libc doesn't support it.