Главная > HOW-TO, Subversion, Unix and Linux > Как настроить SVN+SSH

Как настроить SVN+SSH

0 Introduction
This Guide will explain in easy steps how to setup your Linux server
working for Subversion repository access through SSH client access.

The svn+ssh:// protocol enables you to use SSH client access is throught
the password prompt or using public private keys validation.
No Public/private key generation is necessary to use the simplified
svn+ssh protocol, but it might be a good idea, so that you can avoid
password prompts all the time when using the SVN client access.

This guide assumes that you know how to setup SSH with public/private
keys on the server and on your client, and that you already have
installed Subversion on your Linux box.

1. Install OpenSSH and Subversion binaries (distribution dependend)
Install your binaries on the Linux server (rpm, tgz), following your
distributions installation scheme. To get SSH access working you need
to install the OpenSSH server package.

Also remember:

root user must NOT be allowed to use SSH access (usually default).
Make sure that the SSH server is being started at boot (init-scripts)

2. Access restrictions to Subversion repositories
Using SSH in par with Subversion will only enable access to the
Subversion repositories to users created and active on the server.
To further restrict security, only those users (and root) can «work»
on those files (as created by svnadmin), if logged on to the system
(using the secure shell).

To ensure a clean interface, a new group is created, called svnusers.
Add users to this group that wants access to Subversion repositories.
(Use your favorite GUI admin tool or the command line)

All Subversion users should not be able to su to root (again for
sake of security, compromising remote login and hacking the root password)

2.1 Default umask for Subversion users
When each Subversion user accesses the reposity database through SSH
it is vital that the corresping user doesn’t destroy the group write
permission during the SSH session (using the tunnelled svnserve command)
Therefore, all Subversion users need an addition to their .bashrc file:

umask 002 # allow user + group to write, no other.

Please remember this also when creating new users (that needs Subversion
access) on the server.

2.2 Create a svnadm user account
Create this user with your favorite GUI tool or adduser command, and
add it to the svnusers group.

This user is only for keeping a proper abstraction when working
on the server. The svnadm user will of course be part of the
svnusers group. This user should be used to create new Subversion
projects, execute backup scripts, and work on general maintainance.

As with all Subversion users, the additional entry to the .bashrc file:

umask 002 # allow user + group to write, no other.

3. Create a root path for the Subversion repositories
Create a path in where we will next create our Subversion
repositories (as root):

mkdir -p /usr/share/subversion/repositories

Next, we will restrict access to this area only for root and svn users:

chown -R root.svnusers /usr/share/subversion/repositories
chmod -R u+wrx,g+wrx,o-wxr /usr/share/subversion/repositories

Make sure that you have read and execute permission for root and svnusers
users in the above directory path (check all nodes of the path).

4. Creating a wrapper script for svnserve command
Using the svn+ssh protocol unfortunately discloses the absolute
path of any Subversion project repository stored on the server’s file
system. This is quite unfortunate due to security reasons. The purpose of
this wrapper script is to hide the root directory on your server where you
store all your Subversion repositories.

First of all, rename the original svnserve command into svnserve.bin
(it usually resides in /usr/bin/svnserve)

Paste the following text into your favorite Linux editor and change
the /path/to/repository/root to something useful, eg.:

Save the file as «svnserve», being the root superuser.


# wrap in order to put root in by default
# Script implemented by Adrian Robert <arobert@cogsci.ucsd.edu>


exec /usr/local/bin/svnserve.bin -r /path/to/repository/root "$@"

The -r option ensures that all URL specified paths (only the
projects) will be appended to this root path. In other words this
setup ensures that you only get access to repository projects inside
the root path.

The wrapper script must be executable (and readable) by all.
Only root can write: chmod u+wrx,g+rx-w,o+xr-w svnserve

5. Creating a Subversion project repository
Finally, we’re ready to actually create a Subversion repository that
can be accessed through the svn+ssh protocol. Use svnadm to do the
su — svnadm (log into svnadm user)

then use the svnadmin command to create a Subversion project:

svnadmin create /usr/share/subversion/repositories/project1
(«project1» just being an example, choose your own name)

finally, we need to remove the «other user» access of the new folder
and contents (so that only svnusers have access):

chmod -R o-rwx /usr/share/subversion/repositories/project1

5.1 Configuration of the Subversion project
Before we can open up for the world, we need to configure a few
access settings in the project repository; nobody gets access to the
repository, unless they are SSH authenticated (no anonymous access),
and that the repository is enabled for write access for SSH
authenticated users.

cd /usr/share/subversion/repositories/project1/conf

load the svnserve.conf into your favorite editor and add the following:

anon-access = none
auth-access = write

6. Testing SSH client access (on localhost)
Log in to one of the svn users and try:

svn list svn+ssh://<user-id>@localhost/project1

you should be prompted for a password (and if that’s successful),
you just return back to the command line (because the newly created
project is empty). This test ensures that the SSH server is running
and that the svnserve tunneling is working.

7. Congratulations!
You’re now ready to play with Subversion on your remote clients, doing
all the fun stuff with sub-versioning! Read the Subversion manual
thoroughly and understand the concepts before going into hard core

One advice; use SSH Public/private keys with a user-agent to cache your
ssh passphrase otherwise you will get nuts typing your password over
and over again when issuing all those ssh command sessions.

There’s a quick soultion if you’re a TortoiseSVN user on Windows:

Open Explorer file window, right-click in the file section (get a pop-up),
choose: TortoiseSVN -> Settings -> «Network» Pane-> SSH Client.

…\TortoisePlink.exe -l SSH_login_user_id -pw SSH_password

(if you specify a user ID here, then remember to remove the user ID
from the svn+ssh URL)

Рубрики:HOW-TO, Subversion, Unix and Linux Метки: , ,
  1. Декабрь 8, 2008 в 11:30 пп

    In step 3., what do you mean by «Make sure that you have read and execute permission for root and svnusers
    users in the above directory path (check all nodes of the path).»? Do you mean that all of /usr/, /usr/share/, /usr/share/subversion/ should belong to the svnusers group?

  2. Январь 26, 2009 в 9:25 дп

    It shouldn’t belong to the svnusers. But this group should have access to it. So if you have strict permissions to these folders (for example, root:some_group with 730 access mode) than you need add svnusers ro some_group. In other case you could use 773 access mode.

  3. Voitine
    Октябрь 31, 2010 в 10:47 пп

    Понравился данный пост. Теперь буду старатся заходить к вам чаще!

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: