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 http://pastebin.com/Xk0dF0mc on the client side: sshconnect2.c: void ssh_userauth2(const char *local_user, const char *server_user, char *host, Sensitive *sensitive) { ... ssh_dispatch_set(ssh, SSH2_MSG_EXT_INFO, &input_userauth_ext_info); ssh_dispatch_set(ssh, SSH2_MSG_SERVICE_ACCEPT, &input_userauth_service_accept); ssh_dispatch_run(ssh, DISPATCH_BLOCK, &authctxt.success, &authctxt); /* loop until success */ pubkey_cleanup(&authctxt); ssh_dispatch_range(ssh, SSH2_MSG_USERAUTH_MIN, SSH2_MSG_USERAUTH_MAX, NULL); debug("Authentication succeeded (%s).", authctxt.method->name); } Is the only place where the dispatch for that packet is set. However in kex.c: int kex_input_ext_info(int type, u_int32_t seq, void *ctxt) { ... debug("SSH2_MSG_EXT_INFO received"); ssh_dispatch_set(ssh, SSH2_MSG_EXT_INFO, &kex_protocol_error); ... } Ensuring this packet will only be accepted before authentication. However the server side is different: int kex_send_newkeys(struct ssh *ssh) { ... debug("SSH2_MSG_NEWKEYS sent"); debug("expecting SSH2_MSG_NEWKEYS"); ssh_dispatch_set(ssh, SSH2_MSG_NEWKEYS, &kex_input_newkeys); if (ssh->kex->ext_info_c) if ((r = kex_send_ext_info(ssh)) != 0) return r; return 0; } There doesn't seem to have any logic in the client side that restricts sending ext-info-c in the list of kex algorithms after the first key exchange. However I couldn't find it in my kexinit proposal (even the first one): debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256@xxxxxxxxxx,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@xxxxxxxxxxx,ssh-rsa-cert-v01@xxxxxxxxxxx,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1305@xxxxxxxxxxx,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: chacha20-poly1305@xxxxxxxxxxx,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: umac-64-etm@xxxxxxxxxxx,umac-128-etm@xxxxxxxxxxx,hmac-sha2-256-etm@xxxxxxxxxxx,hmac-sha2-512-etm@xxxxxxxxxxx,hmac-sha1-etm@xxxxxxxxxxx,umac-64@xxxxxxxxxxx,umac-128@xxxxxxxxxxx,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@xxxxxxxxxxx,umac-128-etm@xxxxxxxxxxx,hmac-sha2-256-etm@xxxxxxxxxxx,hmac-sha2-512-etm@xxxxxxxxxxx,hmac-sha1-etm@xxxxxxxxxxx,umac-64@xxxxxxxxxxx,umac-128@xxxxxxxxxxx,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@xxxxxxxxxxx,zlib debug2: compression stoc: none,zlib@xxxxxxxxxxx,zlib debug2: languages ctos: debug2: languages stoc: 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. This bug is not very important anyway because the packet is simply dropped with no consequence. Aris _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
