openssh unix dev - Jan 2017 - Client fails kex after c38ea634893a1975dbbec798fb968c9488013f4a

I have a Putty variant that works well with openSSH up until 7.4. After
git bisecting I found that after the application of
c38ea634893a1975dbbec798fb968c9488013f4a the client fails with host key
mismatch. The commit in question appears to remove vestiges of ssh-1
support but my client is using 2.0. I am trying to work out what in that
commit would lead to the symptoms. I have been through the patch and it
appears to be remove the ssh-1 option processing (-b etc.) but nothing
directly relating to key exchange processing.

I have verified that if I reverse the patch the client works and when I
put it back on it fails.

I assume it is a flow-on affect of something but I am struggling to
connect the dots. Any suggestions of what to look at?

The comment for this commit is:

Remove more SSH1 server code: * Drop sshd's -k option. *
    Retire configuration keywords that only apply to protocol 1, as well
as   the
    "protocol" keyword. * Remove some related vestiges of protocol 1
support.


Thanks, Neale

On Fri, Jan 20, 2017 at 2:49 AM, Neale Ferguson <neale at sinenomine.net>
wrote:
> I have a Putty variant that works well with openSSH up until 7.4. After
> git bisecting I found that after the application of
> c38ea634893a1975dbbec798fb968c9488013f4a the client fails with host key
> mismatch. The commit in question appears to remove vestiges of ssh-1
> support but my client is using 2.0. I am trying to work out what in that
> commit would lead to the symptoms. I have been through the patch and it
> appears to be remove the ssh-1 option processing (-b etc.) but nothing
> directly relating to key exchange processing.
>
> I have verified that if I reverse the patch the client works and when I
> put it back on it fails.
>
> I assume it is a flow-on affect of something but I am struggling to
> connect the dots. Any suggestions of what to look at?
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.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Fri, Jan 20, 2017 at 9:18 AM, Darren Tucker <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.
Also, what is the server config?  In particular, do you have HostKey
specifications?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

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.

F*ck I hate MacOS Outlook Client and the way if stuffs around with plus signs.
See if this works.

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 +83,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)
+debug3: mm_answer_sign: hostkey proof signature 0x55e304423390(83)
?debug3: mm_request_send entering: type 7
?debug2: monitor_read: 6 used once, disabling now
+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: 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]