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

[tom petch <ietfc%btconnect.com@localhost>]

From: ietf-ssh-owner%NetBSD.org@localhost <ietf-ssh-owner%NetBSD.org@localhost> on behalf of Mouse <mouse%Rodents-Montreal.ORG@localhost>
Sent: 08 December 2022 16:25

> After some off-list discussions I've given up on trying to use
> existing keying material for the pre-auth, [...] here's the updated
> form.

Is it just me, or do other people see what looks like missing text?
Here's what I'm seeing:

>    *  In order to encourage adoption by implementers of embedde
> re minimal effort to retrofit to existing SSH
>       implementations, both because embedded systems using SSH are
>       frequent targets and because these systems often only have minimal

<tp>At that point I see

  In order to encourage adoption by implementers of embedded SSH, it
      should require minimal effort to retrofit to existing SSH
      implementations, both because embedded systems using SSH are
      frequent targets and because these systems often only have minimal
      effort applied to keep current with new mechanisms.

which makes sense to me whereas our quotation is grammatical nonsense.

Tom Petch
...

>    of client and server ID strings and adds a simple challenge/response
>    to them, preventing the exchange of any SSH hand
> ords any actual SSH protocol messages, unless the pre-
>    authentication succeeds.  It does this by adding a random challenge
>    in the Comment field of the server's SSH ID, with the client

...

>    It is recommended that imp
> thentication attempts, throttling back responses if too many pre-
>    authentication failures occur in a given time interval.  To further
>    confound attackers, servers may in addition opt to continue with an

...

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B