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

svn+ssh Setup Mini-tutorial

From: Gunther Strube <gbs_at_duoosto.dk>
Date: 2004-03-08 14:56:05 CET

Hi all,

I wasn't happy enough with the svnserve and SSH access descriptions. So,
after having
installed and configured everything, and browsed through the mailing
list to find a solution
for hiding the root path of the SVN repositories, I've made these notes
to my self for
future reference.

However, there might be ways to improve my method. I hope that you can
use my ramblings
in the book and improve the text where necessary.

I think that you should have a complete description (point-by-point) on
using SSH public
and private keys with user agent caching. It would be a good balance to
the Apache setup
description.

Subversion should be a tool that is easy to use (already is!) and easy
to install and configure
(not quite yet).

---
Feature request:
Please add a -r feature (maybe in the svnserve.conf file) to the svn+ssh 
so that you can avoid
the wrapper script (which hides the root path of the SVN repositories 
when using the svn+ssh URL).
---
Regards,
Gunther Strube

*******************************************************************
Setup Guide for Linux Subversion Server, using SSH client access
(using the svn+ssh protocol with svnserve -t)

Gunther Strube (gbs@users.sourceforge.net, March 2004)
*******************************************************************

------------------------------------------------------------------
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.:
        /usr/share/subversion/repositories

Save the file as "svnserve", being the root superuser.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#!/bin/sh
# 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
job:
        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:

[general]
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
commit-mania!

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)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 8 15:51:47 2004

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.