4.27.7 ‘Chokes on PuTTY's full KEXINIT

At the start of an SSH connection, the client and server exchange long messages of type SSH_MSG_KEXINIT, containing lists of all the cryptographic algorithms they're prepared to use. This is used to negotiate a set of algorithms that both ends can speak.

Occasionally, a badly written server might have a length limit on the list it's prepared to receive, and refuse to make a connection simply because PuTTY is giving it too many choices.

A workaround is to enable this flag, which will make PuTTY wait to send KEXINIT until after it receives the one from the server, and then filter its own KEXINIT to leave out any algorithm the server doesn't also announce support for. This will generally make PuTTY's KEXINIT at most the size of the server's, and will otherwise make no difference to the algorithm negotiation.

This flag is a minor violation of the SSH protocol, because both sides are supposed to send KEXINIT proactively. It still works provided one side sends its KEXINIT without waiting, but if both client and server waited for the other one to speak first, the connection would deadlock. We don't know of any servers that do this, but if there is one, then this flag will make PuTTY unable to speak to them at all.