Re: non-interactive user authentication

In a message dated: Mon, 07 Oct 2002 12:32:24 PDT
Colin Putney said:

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

Using rsync as an example:

        rsync -e ssh user@server:/some/path/copied/from /path/copied/to

In this case, rsync doesn't care whether the user invoking the
command is the same as 'user@server', and it doesn't care how ssh
authenticates. The user in question may have used rsa or dsa, ssh
figures all that out.

So, how would you explicitly specify an alternate identity file to
rsync over ssh, since rsync doesn't really provide a mechanism for
passing ssh options to it?

I would provide a simple interface to something like ssh. Let the
user then configure ssh however they want. Every authentication
mechanism is going to have a "normal usage" and then some way to
tweak it to the nth degree. If you allow everything with all
permutations, you'll quickly get bogged down in code that ultimately
doesn't have anything to do with your intended goal; to provide a
killer revision control system.

(Just my $.000002 :)

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

I would just opt to never prompt if the tokens were
passed on the command line. If the authentication fails, send the
user an error stating that. Adding all these options to "work
around" things ends up muddying up the waters and leads to a lot of
code to then maintain.

As a user, I'd rather be told my authentication didn't work, than to
be continually prompted for something which is never going to work,
since the root cause is that my credentials are invalid.

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

Understood, and "same here" :)

(although, looking through some of the Apach modules, there exist a
couple (mod_auth_any and mod_auth_external) which look like they
could be subverted for use with ssh if someone with the proper skills
(i.e. not me) were a little creative).

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

-- 
Seeya,
Paul
--
	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.
	 If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org