i have DilOS, illumos based platform. i have openssh 7.4p1 - the same as OSX couldn't connect to old dropbear embedded with log: root@srv171:~# ssh -v -oKexAlgorithms=+diffie-hellman-group1-sha1 sirius@192.168.1.201 OpenSSH_7.4p1 DilOS-9-11, OpenSSL 1.0.2k 26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 192.168.1.201 [192.168.1.201] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 DilOS-9-11 debug1: Remote protocol version 2.0, remote software version dropbear_0.45 debug1: no match: dropbear_0.45 debug1: Authenticating to 192.168.1.201:22 as 'sirius' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group1-sha1 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY Connection closed by 192.168.1.201 port 22 the same log on OSX - connection closed. is it known issue and need additional flag to client? or it is client issue and need patch/update it?
it is working if in ssh client ssh_config enable: MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160 and use ssh by: ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 sirius@192.168.1.201 i was able to connect to lantronix spyder box
This looks like a bug in the old dropbear server - it's dropping the connection without giving any reason why. Without understanding what is happening at the server, there isn't much the client can do here.
I tried reproducing this with a local build of that (12 year old!) version of dropbear. Surprisingly I was able to reproduce it. On the sever it says: [32036] Jun 23 13:56:04 Child connection from 127.0.0.1:41420 [32036] Jun 23 13:56:04 exit before auth: bad buf_getwriteptr After some experimentation, it seems to be related to the total size of the KEX proposal (I'd guess <512 bytes). If we keep adding redundant MACs to the proposal it fails when the MAC list gets to 350 bytes: $ mac=hmac-sha1; while ssh -p 2022 -o hostkeyalgorithms=ssh-dss -o kexalgorithms=diffie-hellman-group1-sha1 -caes128-cbc -m $mac localhost echo ok; do mac="$mac,hmac-sha1"; echo -n "`echo $mac | wc -c` "; done [...] 330 ok 340 ok 350 Connection closed by 127.0.0.1 port 2022 If you make any of the other algorithm lists longer then it'll fail correspondingly earlier. So, it's a bug or implementation limit in the server. You can work around it on the client side as you have discovered. The client could conceivably use the bug bits in compat.{c,h} to limit what it sends in these cases but I'm not sure it's worth the complexity.
Since it's a bug in such an old server I don't think OpenSSH should try to work around it. You should probably get the server upgraded, but if you can't you can configure around it.
closing resolved bugs as of 8.6p1 release