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

Peter Gutmann <[email protected]> writes:

> 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 ) ) )

Doable, but to me sounds a bit awkward. Alternatively, you could let the
authneticatino be handled by some tcp proxy that doesn't need to be
aware of ssh at all. Client connects to a proxy, authenticates in some
way, and then proxy connects to the actual ssh server (e.g., listening
on localhost only) and forwards traffic.

For what it's worth, at my previous job, when I worked from home, ssh
from my work laptop at home to my office workstation was always via some
magic proxy, but with some other kind of auth than hmac with a shared
secret. And this could use plain openssh with -o
ProxyCommand='invocation of proxy client'. The office workstation was
not directly reachable from the Internet.

I think that's a reasonable option when you (i) don't want to expose ssh
server to the Internet at large, and (ii) are able to operate a proxy
service with some suitable authentication to only allow certain clients
to get through.

In your use case, I take it the proxy should run on the same (embedded)
host as the actual ssh server. It doesn't need any privileges besides
listening on an external port and connecting to localhost, and you'd
want something with minimal attack surface. I'm not aware of a tool like
that, with shared-secret authentication, but it sounds generally useful
to me. Should certainly be easier to use, and likely more secure, than,
e.g., port-knocking tricks.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.