An additional-auth mechanism for SSH to protect against scanning/probing attacks

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

The following was triggered by a comment from Mouse in an off-list discussion,
it'd be nice to have a pre-auth mechanism for SSH that works like the OpenVPN
one where someone connecting to a server can't get past the very first step
until they've proven that they're authorised.  In OpenVPN this is hidden under
the rather misleading name tls-auth, it adds a shared-secret HMAC to the
handshake packets so you can't get past step 1 of any attack because you can't
even start a handshake.  It's a really nice defence-in-depth measure, even
pre-auth 0day won't work any more when this is used.

Obviously this won't work in all situations, but it will be useful for the
zillions of embedded-device SSH implementations where only one or perhaps two
users ever connect and that need protection against the constant three-degree
background radiation of scanning and probing.  The simplest way to implement
this would be to add a challenge-response to the first thing transmitted, the
SSH ID:

Server: "SSH-2.0-softwareversion-challenge"
Client: "SSH-2.0-softwareversion-response"

where challenge = trunc( base64( random ) )
      response = trunc( base64( HMAC-SHA256( shared_secret, challenge ) ) )

Cue debate over whether the challenge and response should be treated as part
of 'softwareversion' or used as the 'comments' string.  And definitely not in
the optional subsequent lines of data which causes some implementations to
choke when they see them.

Peter.