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

Simon Tatham <[email protected]> writes:

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

That really wasn't the use case I had in mind, what I was trying to address
was the staggering amount of stuff that exposes SSH on the public Internet,
e.g:

  Over 60% of Organizations Expose SSH to the Internet
  https://www.infosecurity-magazine.com/news/over-60-organizations-expose-ssh/

Some of that's misconfiguration but a lot of it is also because of operational
need.  Sure, it could be done better, but in practice it isn't.  In particular
I can configure my own network setup to be reasonably secure in terms of
handling incoming SSH, but I can't do anything for any other network that my
code is running on, I need to actually put something in the SSH server code to
achieve that.

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

See above.  Also in the case I'm most concerned with, SCADA, there is no
separate wrapper layer, or separate anything.  The SSH server is baked into
the RTOS kernel (there's no operating system in any conventional sense) so if
it's not addressed at the SSH level there's no other way to address it.

Peter.