Re: non-interactive user authentication

On Monday, October 7, 2002, at 11:26 AM, Paul Lussier wrote:

> In a message dated: Mon, 07 Oct 2002 11:19:49 PDT
> Colin Putney said:
>
>> So, for example, if we supported ssh key exchange, we'd need an
>> --rsa-identity
>> option. No big deal.
>
> Why would you need this option? If you support an ssh key exchange,
> wouldn't you delegate that to ssh and let ssh worry about the key
> exchange, since it already knows about the rsa identity? For that
> matter, what if the person isn't using rsa, but opted to use dsa
> instead?

We'd need the identity option for two reasons:

1) Suppose you want to use an alternate identity? Ssh has the -i
option, but how do we know what to pass to it, if the user can't
specify an identity file?

2) Under the "explicitly-specified" rule I proposed, script-writers
need a way to suppress interactive-resolution of failed authentication.
They'd use the --identity option to do that.

Please understand, I'm not proposing a scheme for ssh-based
authentication. I was just using that to illustrate how the
interactivity rule I proposed generalizes to other (hypothetical)
authentication schemes.

Consider that any authentication scheme should be able to draw
authentication information from three sources:

1) Default values from a cache, a configuration, the user's
environment, etc.

2) Values explicitly specified on the command line.

3) Value obtained by prompting the user.

The rule I propose specifies how to handle failure depending on where
the authentication came from.

Colin Putney
Whistler.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 7 21:33:34 2002