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:
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.