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

Jeffrey Hutzelman <[email protected]> writes:

>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, or even any problem (in the absence of any data it's difficult
to make a statement about potential problems).  This is the first extension in
30-odd years of use so I had to define it in some way, if in another 30 years
someone wants to add a second extension they can specify a means of handling
it.

For the implementers here, do any of you use the Comment field?  If so, what
do you put in it?

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

(If the answer is something like "It uses PAM" then that's usage scenario 1
which the draft specifically doesn't engage with).

>Which public key?

The one public key that's used for auth by the one user.  If there's (say) two
users then try both in turn.

>This needs algorithm negotiation,

Why?

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

Peter.