• Available to the users over the Internet
• *Not* hosted over my DSL/Cable
• Using Apache 1.3
• Secure
• SSL not available

Given these constraints, I couldn’t have a traditional Apache 2.0+https installation of Subversion, rather I needed svnserve. Since I didn’t want to host it at home (my home machines frequently donate vital organs to science), I decided to host it on a virtual server. I’d previously discounted svnserve as a minor footnote, not something that was useful or interesting. Without Apache 2.0 and a dedicated server this imposed a couple more constraints:

• Only one user account
• No access to arbitrary ports for svnserve to listen on

From the Subversion Book, svnserve is:

A lightweight serve(sic) process which can run either as a persistent daemon, or as something automatically launched by inetd when necessary. Clients authenticate via CRAM-MD5 algorithm and speak a custom network protocol.

That’s all fine, but a little further down in the Subversion Book, we find svnserve over SSH, which fits the bill nicely.

The basic premise of svnserve over SSH, is that the client connects via SSH to a host, which spawns an svnserve process to serve the repository data. The Subversion designers built in a bit of *nix synergy here, so that svnserve could handle the repository, and ignore the authentication and encryption, via the -t option (tunnel mode). Tunnel mode assumes that the svnserve process communicates over STDIN/STDOUT with the client.

General Requirements

Subversion command line client

Although this will work with TortoiseSVN, I use the command line client.

*nix server

My virtual host is Linux, but this should work on just about any *nix host. On Windows, your mileage may vary

SSH Access to your virtual host

If your virtual host doesn’t allow SSH, then this will not work

Server SSH Configuration

First of all, your server needs to have Subversion installed. Whether it’s installed by your hosting service, or you install it right to your user account, it really doesn’t matter. Installation to a user account is a little tricky, since you may need to compile Subversion (lots of binaries exist, though).

All that’s really required is editing your .ssh/authorized_keys2 (on Linux) Here’s the line I added to mine:
(Line breaks added for readability) From “Controlling the invoked command” in the Subversion Book


command="svnserve -r /home/jkeyfrom/repo -t --tunnel-user=dwilkins",
no-port-forwarding,
no-agent-forwarding,
no-X11-forwarding,no-pty
ssh-rsa AAAAB3NzaC1yc2EA<snip....snip>DGLSKTFLPzUA9J8xJr1p/w== dwilkins@z60t


This command instructs ssh to run the svnserve command when the specified key is encountered. The Subversion Book suggests the additional ssh options to limit the rights of your Subversion users. If you’ve got users that will be using both shell access and Subversion access, they’ll need two public/private key pairs, one for shell, and one for Subversion.

The options to the svnserve command are:

• -r <repository path>
• -t (instructs svnserve to tunnel)
• --tunnel-user <subversion user>

The <Subversion User> doesn’t have to bear any resemblance to your virtual host user.

Subversion Client Configuration

Your Subversion configuration is in ~/.subversion/config. This file is a pretty standard INI-style file, and in there, you’ll find a [tunnels] section. In the [tunnels] section, add / edit the ssh = line to read something like:

ssh = $SVN_SSH ssh -l jkeyfrom -i /home/dwilkins/.ssh/identity.svn

The options to the ssh command are:

• -l <username> (this is the username of your virtual host account)
• -i <location of your ssh private key for Subversion>

And that’s all there is to it! You can get Subversion SSH keys from each of your team members, and put them in the ~/.ssh/authorized_keys2 file, and they’ll have secure access to your archive, with full accountability of checkins.

Your urls will be of the form:
svn+ssh://example.com/directory

Again, I’m a big fan of Subversion, and I’ll probably be blogging more about it later. All of the information in this article came from the Subversion Book – a must-read for Subversion administrators. Subversion users can generally skip it, and just follow their noses in their Subversion client.

dhw