kex protocol error: type 7 seq xxx error message

mancha
Wed, 24 Aug 2016 19:53:42 -0000

On Wed, Aug 24, 2016 at 07:06:29PM +0200, Aris Adamantiadis
wrote:
> Hi,
>
> mancha and me debugged a problem with OpenSSH 7.3p1 that was reported
> on the #openssh freenode channel. Symptoms were that this message was
> popping on the console during a busy X11 session: kex protocol error:
> type 7 seq 1234
>
> I managed to reproduce the problem, it is related to the SSH_EXT_INFO
> packet that is send by the server every time it is sending an
> SSH_NEWKEYS packet, hence after every rekeying. I reproduced it on my
> system with OpenSSH 7.3p1 and manually rekeying with escape R
>
> [SNIP]
>
> Mancha couldn't reproduce the issue, despite running both OpenSSH
> 7.3p1 client & server from upstream, with an empty configuration file.
> At this point I don't know why he's not affected.

Hello.

I can shed a bit of light on why Aris hit the bug while I didn't when we
both used 7.3p1.

When sshd 7.3 *does* use privilege separation (UsePrivilegeSeparation),
ssh->kex->ext_info_c == 0 on re-keys whether or not the client added
ext-info-c to its kex algos in KEXINIT of first key exchange (setting
ssh->kex->ext_info_c).

When sshd 7.3 *does not* use privilege separation, if a client adds
ext-info-c in KEXINIT for its first key exchange, ssh->kex->ext_info_c
== 1 persists through re-keys and you get a client-side "kex protocol
error: type 7 seq XX" response to the server sending a
"server-sig-algs"
SSH2_MSG_EXT_INFO packet after every SSH2_MSG_NEWKEYS.

Operative code: kex.c:kex_send_newkeys()

        if (ssh->kex->ext_info_c)
                if ((r = kex_send_ext_info(ssh)) != 0)
                        return r;

Ref:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/kex.c.diff?r1=1.112&r2=1.113

Cheers,

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160824/6d181f36/attachment.bin>