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

Peter Gutmann <[email protected]> writes:
> 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.
[...]
> 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"

At first glance, this looked interesting, but now I'm not so sure.

My most obvious use case is exposing the SSH port of a machine in my
home, so that I can SSH back to my own computer when I'm out and about,
without also opening up the whole surface of that SSH server for the
Internet to hammer on looking for holes that Debian haven't fixed yet or
that haven't yet been rolled out by my regular apt update.

But then I thought: hang on, I don't really want to have to configure
all my SSH clients _inside_ my house to know the shared secret for that
server, do I? I'd prefer to deploy this added layer of protection at the
boundary of my house network, keeping the common case easy, and only
requiring the custom tweak on the trusted laptop I take with me when I
travel.

So that suggests that this could _more_ usefully be turned into a
completely separate wrapper layer, rather than baked into the SSH
protocol itself. Then the wrapper could be added somewhere other than
the server itself.

So if I wanted to do this - and I might, now it's been suggested - then
I'd probably do it by writing a separate service that can run on my
firewall, along the general lines of:

    send_line(challenge);
    read_line(response);
    if (response != HASH(secret key || challenge))
        close connection and exit;
    else
        connect to internal-machine:22 and become a passthrough;

and in the SSH client on my laptop, configure a proxy command that
implements the opposite end of the same mechanism. If I have to
configure a secret key in the client anyway, configuring it in the form
of a proxy command doesn't seem any _more_ cumbersome.

So I'm not really sure what's _gained_ by incorporating it into SSH
proper. To my way of thinking, all that does is remove the flexibility
to deploy it conditionally.

Cheers,
Simon
    

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and s%q!=0 and m)(12342649995480866419, 2278082317364501, 1670428356600652640,
5398151833726432125, 645223105888478, 1916678356240619, "<[email protected]>"))