[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Auth in ra_dav

From: Sander Striker <striker_at_apache.org>
Date: 2001-08-24 13:40:25 CEST

> On Fri, Aug 24, 2001 at 01:39:00AM +0200, Sander Striker wrote:
>>> On Thu, Aug 23, 2001 at 10:39:54PM +0200, Sander Striker wrote:
>>>> Hi,
>>>>
>>>> Is it going to be possible to write a different authentication
>>>> mechanism than something that requires a username/password?
>>>> I'm talking about a plugin that might take a username/ssh private
>>>> key file. Ofcourse this should _not_ be stored in the wc. I
>>>> would be willing to invest some time in writing this if I get
>>>> a bit of guidance :)
>>>
>>> Other people have address this.
>>
>> Sorry, I'll go through the archives...
>
> Not in the archives -- this current thread. Specifically: we have two auth
> styles right now, it is extensible, etc etc.
>
>>...
>>> The exact mechanics are unknown. We'll work with Joe and Neon to
>>> see what we can do, and come up with something Good.
>>
>> There is no doubt in my mind about that.
>>
>> In the mean time, I'll see what I can find out about possibly writing
>> a mod_auth_ssh / lib_ssh for per user 'tunnels'. This might have
>> a wider application than subversion, come to think of it.
>
> Eh? Apache 2.0's mod_ssl already handles client certs, if I understand
> things correctly.
>
> [ just reviewed the code... sure looks like it. ]

Yes, I believe it does. But that is not really my point. Or maybe I just
still don't know enough about ssl and friends.

> So I'm not sure what you're thinking about doing. Maybe it is
> already done!
> (which doesn't suck...)

Ok, I'll try and write up what I'm thinking about.

[As a side comment: something similar may well be around. Currently there
 are so many projects that I find it hard to find the ones that have my
 true interest (bigger projects aside). Kind of like 'the best place to
 hide a tree is a forest'.]

Here goes:

Imagine a community site moving over from ssh/cvs to subversion. It would
be very nice if we could 'recycle' the users public keys (which were already
present on the cvs machine) in subversion. What would be needed for that is
probably a mod_ssh in apache and a ssh client lib to make life easier.
Right now with ssh there are two ways to do tunneling:
 - connect as a user to the machine and install an ssh forwarder;
 - write your own protocol and start up the 'server' on the remote end using
   the ssh.

The latter is what cvs has done. This would mean implementing an
alternative
protocol to dav/dav_svn and I don't think that would be a path to take.

The first I don't really consider an option, because IMHO you open up a can
of
worms when you allow user forwarding. And, since in subversion, users don't
have to
have an actual account, I'm inclined to take the direction of not giving
them one.
[in cvs users need a real account on the machine for unix permissions and
the
 sshd authentication]

The alternative is implementing the authentication and encryption of ssh in
a
module, hence mod_ssh (the name is somewhat misleading, unless it could also
do what ssh does now, configurable with options in httpd.conf, but I'm
drifting...).

mod_ssh should simply wait for connections, authenticate the user, and then
serve as an encrypted tunnel. The ssh channel mechanism looks like a
candidate
for this. I must admit that I have always had a weakness for ssh, so that's
probably why I want to do something with it. Implementing it in a mod,
using
apr seems like a nice exercise.

But... I'll go bother some people first about ssl and ssh to get a bit
better
informed. Sorry to have caused another 'interrupt to be raised' snatching
precious time away from M3.

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:36 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.