PuTTY bug unix-kex-packet

Home | Licence | FAQ | Docs | Download | Keys | Links
Mirrors | Updates | Feedback | Changes | Wishlist | Team

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 CVS.)

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.

Reports:

• 000701c3fd23$4a4626e0$0400a8c0@capricho
  followup: 000b01c3fd2a$4822cd80$0400a8c0@capricho
  putty-0.54-0.20040216.3mdk.i586.rpm
• 40379F51.3030603@glendown.de
  server appears to be SSH-2.0-3.1.0 SSH Secure Shell (non-commercial)
  associated with diffie-hellman-group1-sha1 (as opposed to gex)?
  log: ixion:~jacob/putty-wishlist/data-mine/unix-kex-packet.d/putty.log
  protocol looks fine
• 1090364295.14285.12.camel@scrat.iceage
  server is SSH-2.0-3.2.5 SSH Secure Shell
  using diffie-hellman-group1-sha1
  SSH packet log attached - protocol looks fine (although it has extra IGNORE messages interspersed, unlike previous)

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.

Audit trail for this bug.