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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> i think this is overly rigid.  it turns the comment field into an
>> extensibility mechanism, but with other extensions as second-class
>> citizens.  if every such extension does this, you can never use more
>> than one, because they all want to be first.
> Yeah, I'd thought about that but then I can't remember ever seeing a
> Comment field used for anything, let alone extensions, so it didn't
> seem like it'd be a big problem,

Probably not.  This amounts to "nobody else has come up with any other
use, so I can use this non-extensible version".

Of course, you can spec whatever you want.  But, if I were to build an
implementation of it, I would probably ignore the must-be-first part of
the spec.

Not that it matters much to me either way.  I don't expect to
participate in this scheme, and the facilities I'm adding to moussh to
support what I am likely to do could be used for this regardless of
whether that part is kept.

>> This doesn't work. The server cannot compute or validate such a
>> challenge, because it almost never knows the password.
> If it doesn't know the user's password, how does it authenticate
> them?

It doesn't know the user's password *then* - the user typically
doesn't type it until the server offers password auth and the client
decides to try it.  In some cases not at all; the server may not even
offer password auth for all the client knows at that point.

For the embedded use case, the client could assume it knows what auth
method(s) the server will offer, but that's more of the server-specific
configuration this thing is trying to get away from.

>> This needs algorithm negotiation,

> Why?

> Seriously, why?  I can't think of any reason why you'd need this.

My first answer is, to replace with a better algorithm when (I do not
say "if") the day comes that SHA256 is deemed too weak.

I don't see any need for algorithm *negotiation*.  But if I were
designing it (for more than personal use - the personal-use variant I
have partly in place does not have an algorithm field) I would put an
algorithm field in there somewhere, probably in the server challenge;
for these purposes I don't see anything wrong with the server requiring
the client to be prepared to handle whichever algorithm the server is
configured to use.

/~\ 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