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

Re: what is the best way to set up secure svn server for people outside the firewall to access it?

From: Andrey Repin <anrdaemon_at_freemail.ru>
Date: Fri, 13 Nov 2009 12:52:45 +0300

Greetings, Thomas Harold!

>> For example, I would like to setup a https svn site just like
>> http://unfuddle.com/ or http://svnrepository.com/. I tried them, but i
>> dont see how https works in terms of security.

> If the SVN server is a Linux/Unix server, I'm partial to svn+ssh.

> Advantages:

> - No storage of passwords in the working copy (or doesn't http/https
> suffer from this problem?).

Irrelevant. Any reference to working copy in discussion about server just
irrelevant.

> - Uses public SSH key pairs. Less/No worries about stolen or sniffed
> passwords, you just have to worry about stolen private keys.

Irrelevant. Apache could be configures in many ways, including authorization
through client-server certificates.

> - SSH keys can be loaded into an SSH agent on the client to avoid
> additional password prompts.

See above. Irrelevant.

> - SSH keys can be locked down on the server side so that they're only
> useful for interacting with the svnserve program. That makes it a good
> bit more difficult for the attacker, even if they have the private SSH key.

That is the very idea of using client-server certificates, but in majority of
situations it is unnecessary bloating and does nothing but give admin
headache.

> I tend to find https (SSL) to be arcane and confusing to setup.

Four strings in Apache configuration is confusing? >.< I mean, four strings in
addition to the four that setting up SVN DAV itself.

> I've setup https before, but my comfort level with svn+ssh is a lot higher.
> And I'm not comfortable configuring Apache yet.
> But that's just a personal bias against https.

That's only your issue. As you said, it's highly personal.
If you have ssh infrastructure already, it probably easier for you to adapt it
for svn, but major disadvantage of this scheme is that repository being
accesses with many user credentials, repository hooks could be running with
credentials different from the user, and smallest mistake in setting user
rights and umasks could lead to repository destabilization.
Also repository filesystem is open for (un)intentional destruction using
svnadmin (server-only tool to manipulate repository on a ground level).
svnserve and dav free from this issue, the repository always accessed through
the single user credentials - the ones server running from, and directory
storage inacessible in any direct way.

--
WBR,
 Andrey Repin (anrdaemon_at_freemail.ru) 13.11.2009, <12:41>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2417481
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-13 10:55:54 CET

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.