kex protocol error: type 7 seq xxx error message
mancha1 at zoho.com
Thu Aug 25 05:53:42 AEST 2016
On Wed, Aug 24, 2016 at 07:06:29PM +0200, Aris Adamantiadis wrote:
> 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
> 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.
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
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 ((r = kex_send_ext_info(ssh)) != 0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the openssh-unix-dev