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

On Tue, 13 Dec 2022, Peter Gutmann wrote:

> 
> Niels Möller <[email protected]> writes:
> 
> >I think you mentioned the possibility of instead adding magic lines prior to
> >the SSH-line, a line "Preauth-SSH: whatever". Is there some reason that can't
> >work?
> 
> An informal test of a few client-mode implementations found exactly one that
> handled this correctly (hat tip to PuTTY), others wouldn't connect or ran into
> crypto failures like incorrect keys, the latter presumably because they hashed
> in the additional text lines or something.  So this seems very brittle,

fwiw OpenSSH handles lines from the server before the SSH-banner just
fine:

[djm@djm ~]$ echo "echo blah; doas /usr/sbin/sshd -i" > c; chmod a+x c 
[djm@djm ~]$ ssh -oProxyCommand=~/c -Snone ::1 echo ok                 
ok

Given that the whole purpose of your proposed extension is to refuse
access to clients that don't implement it and that lack the password, I
don't see how brittleness is a concern.

Either the client doesn't speak the protocol extension and therefore
wouldn't have been allowed access anyway, or it does and its access is
gated on knowing the password.

I'd much rather see the existing mechanism used than to overload the SSH
banner line. The SSH banner line is a bit special in that its contents
are guaranteed to be bound into the key exchange hash, and so IMO any
extension that wants to use the banner line should be one that benefits
from this property. I don't see any such benefit here, so pre-SSH-
signalling seems fine for this purpose.

I am aware of one (private) server-side protocol extension that uses the
SSH banner line for signalling (and which does need binding into the KEX
hash) and AFAIK it would need rework to coexist with this proposal.

-d