mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-03-17 04:18:38 -05:00
5e2acd9af7
We've occasionally had reports of SSH servers disconnecting as soon as they receive PuTTY's KEXINIT. I think all such reports have involved the kind of simple ROM-based SSH server software you find in small embedded devices. I've never been able to prove it, but I've always suspected that one possible cause of this is simply that PuTTY's KEXINIT is _too long_, either in number of algorithms listed or in total length (especially given all the ones that end in @very.long.domain.name suffixes). If I'm right about either of those being the cause, then it's just become even more likely to happen, because of all the extra Diffie-Hellman groups and GSSAPI algorithms we just threw into our already-long list in the previous few commits. A workaround I've had in mind for ages is to wait for the server's KEXINIT, and then filter our own down to just the algorithms the server also mentioned. Then our KEXINIT is no longer than that of the server, and hence, presumably fits in whatever buffer it has. So I've implemented that workaround, in anticipation of it being needed in the near future. (Well ... it's not _quite_ true that our KEXINIT is at most the same length as the server. In fact I had to leave in one KEXINIT item that won't match anything in the server's list, namely "ext-info-c" which gates access to SHA-2 based RSA. So if we turn out to support absolutely everything on all the server's lists, then our KEXINIT would be a few bytes longer than the server's, even with this workaround. But that would only cause trouble if the server's outgoing KEXINIT was skating very close to whatever buffer size it has for the incoming one, and I'm guessing that's not very likely.) ((Another possible cause of this kind of disconnection would be a server that simply objects to seeing any KEXINIT string it doesn't know how to speak. But _surely_ no such server would have survived initial testing against any full-featured client at all!))