Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
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:
@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.)