Bug 2725

Summary:	can't login
Product:	Portable OpenSSH	Reporter:	IgorK <igor>
Component:	ssh	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED INVALID
Severity:	normal	CC:	djm, dtucker
Priority:	P5
Version:	7.4p1
Hardware:	68k
OS:	Mac OS X

Description IgorK 2017-05-29 20:45:59 AEST

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?

Comment 1 IgorK 2017-05-29 21:45:30 AEST

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

Comment 2 Damien Miller 2017-06-09 13:31:53 AEST

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.

Comment 3 Darren Tucker 2017-06-23 14:39:09 AEST

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.

Comment 4 Darren Tucker 2017-07-27 13:49:38 AEST

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.

Comment 5 Damien Miller 2021-04-23 15:04:34 AEST

closing resolved bugs as of 8.6p1 release