Powered by:

ohost

Bulgarian mirror 10 Gbps

Protocols: HTTP, HTTPS, FTP, RSYNC
Contact Us: support@ohost.bg

PuTTY wish handle-unimplemented

PuTTY wish handle-unimplemented

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: Handle SSH2_MSG_UNIMPLEMENTED more usefully
class: wish: This is a request for an enhancement.
difficulty: fun: Just needs tuits, and not many of them.
priority: medium: This should be fixed one day.

If an SSH server sends us SSH2_MSG_UNIMPLEMENTED, we currently report it as "Strange packet received: type 3" and close the connection. It would at the very least be better if we reported it as SSH2_MSG_UNIMPLEMENTED, and ideally also gave some idea of what the server had claimed not to understand.

It's not completely clear to me how far we can sensibly take this sort of error reporting, but we could usefully at least be prepared to deal with common cases. For instance, servers which don't support rekeying: when we initiate a rekey, we could remember the sequence number of the SSH2_MSG_KEXINIT we send out, and if we subsequently see SSH2_MSG_UNIMPLEMENTED citing that sequence number then we could give an error message which actually suggested a corrective measure to the user ("try manually enabling 'Handles SSH-2 key re-exchange badly' in the Connection > SSH > Bugs panel").

(In that particular case, it might even be possible to abandon the rekey and proceed with the rest of the connection – see kexinit-unimplemented – although I don't know if servers would in general even cope with that, and also I think it would be a bad idea not to at least warn the user of the drop in security.)

If we felt enthusiastic, we could try being more ambitious: it might be feasible, for instance, to keep track of all the message type codes for messages we've recently sent out. Whenever we see any message we can identify as the reply to some specific thing we sent, we can delete that and everything before it from our queue; then for any SSH2_MSG_UNIMPLEMENTED, we'll always be able to specify exactly what type of message the server didn't understand.

All of this, of course, assumes the server is sending out SSH2_MSG_UNIMPLEMENTED messages containing a correct packet sequence number. Some servers (in violation of the SSH spec) do not bother, and just put zero in the sequence number field when they send SSH2_MSG_UNIMPLEMENTED.


If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2017-04-28 16:52:45 +0100)
Mirror hosted by: OHOST LLC