Subversion rocks! I’ve been a fan of Subversion for the past 4 years or so. Recently, I needed to give Subversion access to a small team, and my constraints were:
- 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
%20not%20found.png)
