MAC algorithm negotiation and ssh.be

[sfromis]

Trying out ssh.be, I quickly got it to work with a default ssh client command in Linux, after getting past the "surprise" of not getting a > prompt when ready for commands, after entering the password.

Next step was feasibility for automation, where I have my own client (tested with Linux SSH servers) based on the sshj client library which fails with this message:

Unable to reach a settlement of Client2ServerMACAlgorithms: [hmac-sha1, hmac-sha1-etm@openssh.com, hmac-sha1-96, hmac-sha1-96@openssh.com, 
hmac-md5, hmac-md5-etm@openssh.com, hmac-md5-96, hmac-md5-96-etm@openssh.com, hmac-sha2-256, hmac-sha2-256-etm@openssh.com, hmac-sha2-512, 
hmac-sha2-512-etm@openssh.com, hmac-ripemd160, hmac-ripemd160-etm@openssh.com, 
hmac-ripemd160-96, hmac-ripemd160@openssh.com]
 and []

The key here is the last bit, when the 2nd half of the matching (proposal from the ssh.be server) is an empty list. This makes sense when the function kexinit_to_client has:

        var mac_algorithms_client_to_server = ""
        var mac_algorithms_server_to_client = ""

My conclusion became that ssh.be expects it to be ok without any MAC algorithms, but sshj expects the server to have some candidate algorithm(s) on offer.

Not sure if I'm reading this right, but the check_packet and encrypt functions appears to be using crypto.CHACHA20_POLY1305 to create/check a MAC. Is this based on an expectation of this being "the default" MAC algorithm without a negotiation match?

I was wondering if this should or even could be advertised, but my client library does not include it, and this comparison table of SSH across a lot of implementations does not mention anything looking like that. The ones with the broadest support are hmac-sha1 and hmac-sha2-256, but several others are common too.

What do you think, @Staars ?

[Staars]

I did not plan to support outdated clients, but you can add other ciphers if you like.
Chacha20-Poly1305 is the fastest solution on low end hardware and BearSSL does not have hardware acceleration anyway. I consider this a no-brainer.
The choice of the key exchange algorithm is less easy, but I opted for a newer one in hope to have it supported for a long time. This part is debatable.
With enough space (on the ESP) it would of course have been nice to support multiple algorithms, but I do not see this as a goal for this demo.

My point of view is that the tiny, tiny ESP32 does provide one solution, that is modern and safe (with the knowledge of today) and the client on much bigger hardware has to deal with it - not the other way around.
I see this as a fresh start and all well maintained clients on my computer did work without a problem. Only some of the crappy apps on the iPad where too outdated.

But of course it is interesting to know, what is used in the wild and what is obviously not recommendable in general.