Better handling of SSH_MSG_KEX_DH_GEX_REQUEST

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

A problem I've run into more than once with SSH servers occurs with
SSH_MSG_KEX_DH_GEX_REQUEST and servers that are configured to use weird key
sizes, which some people seem to really like doing [0].  If the client
proposes a range of sizes with SSH_MSG_KEX_DH_GEX_REQUEST and the server has
been set up to require something outside this range, the client will see the
server disconnect at this point with nothing more than some generic response
like SSH_DISCONNECT_KEY_EXCHANGE_FAILED.

The problem is that there's no way for the server to send a
SSH_MSG_KEX_DH_GEX_NAK to say "you asked for X but I can only do Y".  Because
the key size exchange isn't part of the normal handshake, you can't look at
the client and server kex strings to see where the incompatibility lies,
leaving as the only option repeatedly guessing values until the server stops
aborting the handshake at that point.

Could people who work on server implementations consider returning an error
message in response to a non-matching SSH_MSG_KEX_DH_GEX_REQUEST that informs
the client what the problem is?  In other words explicitly respond with "you
asked for X but I can only do Y" in the SSH_MSG_DISCONNECT.  This would make
it a lot easier to diagnose failures of this kind.

Peter.

[0] Popping up a message that says "Please call an adult to configure the
    server for you" probably won't go down well.