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

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

[Repost since the first attempt got greylisted and rejected]

The following was triggered by a comment from der 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.