Client fails kex after c38ea634893a1975dbbec798fb968c9488013f4a

[Neale Ferguson]

Thanks for the response. Here is the diff between the bad and good
instances. Apart from the order of some exchanges and stuff that should be
different between sessions nothing really stands out:

@@ -83,20 ﯍,26 @@
 debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256
compression: none [preauth]
 debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
 debug3: receive packet: type 30 [preauth]
 debug3: mm_key_sign entering [preauth]
 debug3: mm_request_send entering: type 6 [preauth]
-debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
-debug3: mm_request_receive_expect entering: type 7 [preauth]
-debug3: mm_request_receive entering [preauth]
 debug3: mm_request_receive entering
 debug3: monitor_read: checking request 6
 debug3: mm_answer_sign
-debug3: mm_answer_sign: hostkey proof signature 0x55b482415130(83)
輪鮺: mm_answer_sign: hostkey proof signature 0x55e304423390(83)
 debug3: mm_request_send entering: type 7
 debug2: monitor_read: 6 used once, disabling now
輪鮺: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
輪鮺: mm_request_receive_expect entering: type 7 [preauth]
輪鮺: mm_request_receive entering [preauth]
 debug3: send packet: type 31 [preauth]
 debug3: send packet: type 21 [preauth]
 debug2: set_newkeys: mode 1 [preauth]
 debug1: rekey after 4294967296 blocks [preauth]
 debug1: SSH2_MSG_NEWKEYS sent [preauth]
 debug1: expecting SSH2_MSG_NEWKEYS [preauth]


On 1/19/17, 5:18 PM, "dtucker at dtucker.net on behalf of Darren Tucker"
<dtucker at dtucker.net on behalf of dtucker at zip.com.au> wrote:

>Could you post the server-side debug logs (sshd -ddd) from before and
>after the suspect commit?  Comparing them would give some indication
>of what's different.