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

Re: svn: Authorization failed

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Mon, 17 Aug 2009 08:08:37 -0400

On Sat, Aug 15, 2009 at 2:47 AM, Ryan
Schmidt<subversion-2009b_at_ryandesign.com> wrote:
> On Aug 15, 2009, at 00:47, Erick Calder wrote:
>
>>> Stop right there. Proceed *DIRECTLY* to the use of svn+ssh to get a
>>> much better security model. Subversion's tendency to store passwords
>>> in clear text is very nasty, and this is the most reliable fix for
>>> it,
>>> one used by Slashdot and other security conscious systems
>>
>> the svn+ssh model is problematic because I really don't want to give
>> system accounts to those that will use svn...
>
> Fortunately, you don't need to. :) Everyone can share a single
> account to access Subversion on the server via svn+ssh. See this FAQ:
>
> http://subversion.tigris.org/faq.html#ssh-authorized-keys-trick

Thank you for pointing that out, Ryan. Yes, the SSH keys can be
restricted in their function to run only one command, and not provide
shell access. This is used effectively by Subversion, git, and
Perforce. (I used to work at a company that was involved in
integrating this into Perforce.) It is precisely how Sourceforge does
Subversion and git access to their source control repositories, so
it's a popular and well-known approach.

git has a very useful tool called 'gitosis' for managing the user keys
for multiple repositories. I've looked for a similar tool for
Subversion, but gotten little traction finding one, and lack time (and
perhaps some critical skills) to write one myself.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384300

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-17 14:09:46 CEST

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

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