German mirror provided by / Deutscher Spiegelserver von  &  SEO LEO

PuTTY wish kexinit-filtering

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

We've occasionally had reports of SSH servers disconnecting as soon as they receive PuTTY's SSH_MSG_KEXINIT.

The server doesn't generally say anything useful about what it doesn't like about our KEXINIT packet. But since those reports generally involve small and simple ROM-based SSH servers of the kind you find in small embedded devices, a reasonable guess is that PuTTY's KEXINIT is simply too big in some way for a limited server to cope with, and is overflowing some internal limit of the server, which then gives up on the connection.

There are quite a few possibilities for what 'too big' might mean:

• the overall length of the KEXINIT packet as a whole is too big
• one of the individual strings in the packet (being a comma-separated list of algorithm names) is too long
• one of those comma-separated strings lists too many algorithms
• one of the individual algorithm names is too long (especially likely given the nonstandard ones that end in suffixes of the form @very.long.domain.name).

Servers don't generally have useful error reporting that would indicate which of those is the problem. (Not entirely their fault: the SSH protocol itself contains no message type for reporting a detailed complaint about a KEXINIT.) So it's hard to guess exactly what the problem might be and produce a targeted workaround.

However, there's a general class of workaround that might work for a wide range of problems of this type: PuTTY waits until it sees the KEXINIT message sent by the server, and filters its own KEXINIT so that it leaves out any algorithm name that the server didn't also specify. That way, PuTTY's KEXINIT will be almost no longer than the server's, and won't contain any specific long lists or long strings. So assuming the server is sending a KEXINIT of a type it would be equally happy to receive, this should work around any server bug of this kind.

This doesn't change the outcome of algorithm negotiation, because the negotiation process will always select algorithms that appeared in both KEXINIT messages. So any algorithm left out by this workaround wasn't going to be picked anyway, and the remaining ones appear in the same preference order.

On the other hand, this is a violation of the SSH protocol because the client and server are supposed to send their KEXINITs independently, neither one waiting for the other. If one side of the connection waits for the other to speak first, nothing goes wrong – but if both did, the connection would deadlock! For that reason, this workaround is never enabled by default. You have to turn it on deliberately, if you're having trouble with a particular server.

(One small technical detail: PuTTY will still include the special string ext-info-c in the list of key exchange algorithms, which is not an algorithm name at all, but a signal defined by RFC 8308 to enable protocol extensions such as RSA using SHA-2 hashes. By design, that string is never sent by an SSH server, so this filtering policy implemented literally would always throw it out. But if we did throw it out, then RSA/SHA-2 would stop working, even if the server supported it. So if any server is unhappy with that string in particular, then an even more draconian workaround might be needed with a separate config option.)