error: Corrupted MAC on input. [preauth]

[l***@bentleyemail.net]

_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

[Peter Stuge]

Hi Eric,

I have an embedded linux project using buildroot which I've included
libssh2 in. The current configuration also is using dropbear.
I am attempting to use curl with scp to retrieve a file stream but am
getting an error.

Thank you for reporting! If master still has this issue we need to fix it
before release, which should be quite soon.

curl: (2) Failure establishing ssh session: -43,
I turned sshd debug up to level 3 and see: the error
Corrupted MAC on input. [preauth] (full error log at end of this post)

..

sshd[361421]: debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]

..

sshd[361421]: debug1: SSH2_MSG_NEWKEYS received [preauth]
sshd[361421]: debug2: set_newkeys: mode 0 [preauth]
sshd[361421]: debug1: rekey in after 4294967296 blocks [preauth]
sshd[361421]: debug1: KEX done [preauth]
sshd[361421]: Corrupted MAC on input. [preauth]

Please provide us with more information:

What processor does your embedded system have? In particular endianess
and native bit size (32/64?)

What MAC is negotiated by the dropbear and OpenSSH clients you tested?

Are results identical with a server running an unpatched upstream OpenSSH?


Thank you and kind regards

//Peter
_______________________________________________
libssh2-devel https://

[l***@bentleyemail.net]

_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

[Peter Stuge]

Hi Eric,

I'm happy to help but my responses may be delayed as I'm getting ready
to head out for a few days of vacation (leaving in 12 hours)

Oh that sounds amazing! I hope you have a good time.

hmac-sha2-256 compression: none [preauth]

..

Post by Peter Stuge
What processor does your embedded system have? In particular endianess
and native bit size (32/64?)

model name : ARMv7 Processor rev 1 (v7l)
Hardware : Atmel SAMA5
/bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, BuildID[sha1]=51f5566abbeca4cee5e53734090d7d37b33deedb,
for GNU/Linux 3.2.0, stripped

Thanks, little endian ARM.

Post by Peter Stuge
What MAC is negotiated by the dropbear and OpenSSH clients you tested?

..

client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]

..

<implicit> compression: none [preauth]

This is interesting and provides some clues. All three clients end up
using different ciphers/MACs with only libssh2 using hmac-sha2-256.


It would be great if you could try OpenSSH with the same cipher+MAC
as libssh2 and provide the server debug log also for that connection:

ssh -oCiphers=aes128-ctr -oMACs=hmac-sha2-256 server

Post by Peter Stuge
Are results identical with a server running an unpatched upstream OpenSSH?

Unfortunately, I do not have a server running this version. My sshd
server is
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f 31 Mar 2020

Okay. The upstream source code is fairly easy to build but I understand
that you're leaving literally in hours. If you can try the OpenSSH
client with specific cipher and mac that log would be very helpful.


Thanks

//Peter
_______________________________________________
libssh2-devel https://cool.hax

[l***@bentleyemail.net]

_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

[Peter Stuge]

Hi Eric,

Thanks for these additional logs, I think we found the issue!

# ssh -v -oCiphers=aes128-ctr -oMACs=hmac-sha2-256 192.168.1.123
OpenSSH_8.5p1, OpenSSL 1.1.1k 25 Mar 2021

..

debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none

Now the OpenSSH client uses the same cipher and MAC as libssh2 did,

ssh_dispatch_run_fatal: Connection to 192.168.1.123 port 22: error in libcrypto

This error message from the client shows that the problem is actually
with libcrypto (OpenSSL) and not with libssh2. I guess that the
embedded build of OpenSSL disables a feature required for hmac-sha2-256.


It is a different - but also relevant! - problem that libssh2 behaves
the way it does in this case. I don't know if it fails to check
availability or whether it just needs to provide an error message
which makes sense. Either way it's sloppy and we should fix that.


But to answer your original question, for your connection to succeed
with curl/libssh2 and with OpenSSH using same cipher and MAC you'll
have to work on how OpenSSL is being built.

Once OpenSSH works with those options libssh2 will likely work as well.


//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel