PuTTY bug unix-kex-packet

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Unix: "expected key exchange reply packet from server" and crash
class: bug: This is clearly an actual problem we want fixed.
present-in: 0.54
fixed-in: 2005-01-08 88c52fa85fdfa000a33d350138b10c8ebfa85965 (0.58)

We've had a couple of reports of the Unix version putting up the "new host key" dialog, but then immediately putting up a "PuTTY Fatal Error: expected key exchange reply packet from server" error box over it and then crashing. I've reproduced this by connecting to one of our correspondents' servers.

If the host key is already in the database, the connection goes through fine. The fault doesn't appear to happen with the Windows version, nor with Unix plink.

Workaround: add the host key to the database first. (Apparently this can be done by setting "close window on exit" to "never" in the first session, or use contrib/kh2reg.py in PuTTY version control.)

More detail: In PuTTY's SSH packet log, what appears to distinguish failing from successful connections is that in the latter, PuTTY logs sending a NEWKEYS before logging receiving one, whereas in the former, it doesn't log sending one at all. So in Windows and Unix-plink connections with and without the host key prompt, and Unix PuTTY without the prompt, we get something like

Incoming packet type 31 / 0x1f (SSH2_MSG_KEXDH_REPLY)
Event Log: Host key fingerprint is:
Event Log: ssh-dss 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Outgoing packet type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Incoming packet type 21 / 0x15 (SSH2_MSG_NEWKEYS)

whereas in Unix PuTTY with the prompt, we have

Incoming packet type 31 / 0x1f (SSH2_MSG_KEXDH_REPLY)
Incoming packet type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: expected key exchange reply packet from server

while waiting for the user to respond to the prompt.

Tracing the code indicates that the SSH code gets a DH reply packet, goes to verify the host key, goes to put up a message box, enters gtk_main()... and the next thing we know is that ssh_receive() is prematurely invoked on the next packet (NEWKEYS), re-entering do_ssh2_transport() and looking for a DH reply packet again (and failing). So the messagebox isn't causing enough blocking. Probably something about the way we're using Gtk.


SGT, 2005-01-07: Simplest answer, I think, is to use sk_set_frozen() to ensure that the SSH connection in question doesn't accept any more data while we're in the middle of asking the user about something.

If you want to comment on this web site, see the Feedback page.
Audit trail for this bug.
(last revision of this bug record was at 2016-12-27 11:40:22 +0000)