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

Re: Passswords not encrypted

From: Thomas Harold <tgh_at_tgharold.com>
Date: 2007-06-14 15:03:13 CEST

Joseph Mocker wrote:
> Benjamin Podszun wrote:
>> Joseph Mocker wrote:
>>> What would be nice is an "ssh-agent" type of capability for
>>> subversion. Where one could authenticate once for a session, and the
>>> agent would keep track of the authentication/password. When
>>> authentication is needed, subversion would query the agent first.
>> Why don't you use svn+ssh then?
> Main reasons, per the "red-bean" subversion book:
> * Requires users to be in same system group, or use a shared ssh key.
> * Can lead to file permissions problems.

It's actually not that bad.

1) Create the user accounts on the SVN server (or use existing ones)

2) Create a group to "own" the SVN repository. We usually create one
group for each repository (i.e. "svn-repos1" for a repository called
"repos1"), then add anyone who needs read/write access to that
repository to the group. Alternately, you could have multiple
repositories controlled by a single user group.

3) Assign permissions and ownership of the repository. So if your
repository is in "/var/svn/repos1":

# cd /var/svn
# chmod -R 770 repos1
# chmod -R g+s repos1/db
# chgrp -R svn-repos1 repos1

The "g+s" is required whether you are using BDB or FS as your storage
method. That way when users create or modify files in the repos/db
folder, ownership stays correct.

(I haven't had to muck with umasks, yet. Possibly because the defaults
were correct. So we have yet to need to "wrap" svnserve into a script.)

4) Have the users create SSH key pairs that will only be used for SVN
access. In our case, since the server is dedicated to SVN, this is the
only key in the user's ~/.ssh/authorized_keys file. Our users cannot
login and get a shell account because they don't know the password on
that server and their SSH key is limited to running svnserve.


Now to lock the key down, edit the ~/.ssh/authorized_keys file and put
the following on the front of the key line that will be used by the
client machine:

command="/usr/bin/svnserve -t -r /var/svn",no-agent-forwarding,no-pty

This forces the connection to run the "svnserve" command in tunnel mode.
So this SSH key cannot be used to login or run any other commands on the
server. It also changes the SVN root path to /var/svn. You will want to
also add "no-port-forwarding" and "no-X11-forwarding" if you have not
disabled those in your /etc/ssh/sshd_config file.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 14 15:04:01 2007

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.