Thursday, November 03, 2005

Subversion and SSH

A while back, I set up a Subversion repository on my home Linux server to keep a handle on all of my projects. Since this machine was really also my main desktop (and MythTV box), there were really no issues that couldn't be handled from the commandline.

A while later, I expanded my computer collection and wanted to try to get at the SVN repository from there as well. Also, I had accumulated several scripts at home that I wanted *easy* access to from work. Pairing SSH with SVN makes all of this as easy as accessing the SVN repository from the local server.

First order: get SSH working using public key authentication. There are lots of tutorials on the web for this, but the following worked for me:

  1. On the server, generate your keys: "ssh-keygen -t dsa -b 1024". See ssh-keygen manpage for details on this command. Basically, this creates a 1024 bit DSA key pair for you. Don't forget to enter a good passphrase for the key!
  2. Make sure that your private key (~/.ssh/id_dsa) and the .ssh directory are only readable by you -- The directory should be "chmod 700" and the file "chmod "600". Many ssh servers will not allow key-based authentication if this is not the case!
  3. Copy the public part of the key (~/.ssh/id_dsa.pub) to each client. Append it to the file "~/.ssh/authorized_keys2"
SSH should now be working using the keys. When you ssh from one of the clients to your server you should be prompted for your key passphrase, but NOT your server password. Once you enter it, you should be in.

Now, entering a passphrase every time you want to use SSH sucks, doubly so when using Subversion as you will be prompted for it several times for each transaction. Not fun. To get around this, you can run an ssh-agent locally that will hang onto your decrypted key for you. All you need to do is enter the passphrase *once* using the "ssh-add" command and all logons to the server won't prompt you. This works, but you need to have the agent running, and there should be environment variables set pointing to it. If you start the agent in one xterm and want to use it in another, well, this also gets tricky. Fortunately, Keychain can handle all of this for you. It's a simple shell script that handles the agent for you. All I did was add a line to start it to my .bashrc and another line to source the environment variables it sets:

 # Start keychain for ssh-agent
 /usr/bin/keychain

 [[ -f $HOME/.keychain/$HOSTNAME-sh ]] &&     
    source $HOME/.keychain/$HOSTNAME-sh
Now, all I need to do is enter my ssh passphrase once after logging on using ssh-add, and everything works smoothly from there.

On to Subversion! When I initially created my Subversion repositories, I put them on the server at /subversion. With SSH from each client working, accessing this was disappointingly simple. On the client:

svn co svn+ssh://username@my_svn_server/subversion/project1
Compare this to what I would do on the local server:
svn co file:///subversion/project1
It's a bit more typing, but this is really only needed once when checking out the code. After that, svn commands such as "svn stat" work as they always do.

The only thing to watch out for is if the Subversion repository is going to be shared by several people. Because of how the svn client runs the Subversion server on the remote end, it will be running as the user. This can mess up filesystem permissions in the repository if things aren't set up correctly. There's a whole section on this in the Subversion book, and this applies to local SVN access just the same as it does to SSH access.

One final thing -- since Mac OS X doesn't come with Subversion preinstalled, I needed to grab some binaries for this. The Subversion Page lists both Fink packages and prebuilt binaries (from http://metissian.com/projects/macosx/subversion/. Being lazy, I grabbed the prebuilt binaries and haven't had a problem with them.

0 Comments:

Post a Comment

<< Home