Flashmark

Avatar

Public key authentication when tunnelling Subversion repository access over SSH

It is relatively straightforward to allow access to the repository by tunnelling the Subversion protocol over ssh. The use of public key authentication is necessary in this scenario, and also makes life easier when implemented correctly. It is possible to use a single system account for multiple Subversion users, none of which have to be given command prompt access.

The public/private key pair generated here will be used exclusively for repository access; it will be configured to run a specific command (the Subversion server) automatically and as such cannot be used for command prompt access. If you need to use the same account for command prompt access, you will need to set up another key pair (or just use password logins).

First a public / private key pair is required. I am creating this and saving it as svn_<username> instead of the default (as this will be used for general ssh access). It is a good idea to use a passphrase - your users can use a key agent to avoid being prompted for it all the time.

$ ssh-keygen -t rsa -f ~/.ssh/svn_user
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/svn_user.
Your public key has been saved in /home/user/.ssh/svn_user.pub.
The key fingerprint is:
??:??:??:??... user@serve

Now we need to append the public portion of this key to the authorized_keys file so the ssh daemon knows about it.

$ cat ~/.ssh/svn_gjm.pub >> ~/.ssh/authorized_keys

Next step is to prepend a forced command to this key entry so it automatically invokes the Subversion server. Open up the ~/.ssh/.authorized_keys file in your favourite editor. The last line in the file will contain your new key. The line should look like this when you are finished:

command="/usr/local/bin/svnserve -t -r /var/repos",no-port-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqi6WkturG.......

It is probably worth checking out the manpage for svnserve at this point if you are not sure what is going on here. Clients logging in with this key will now have the svnserve command invoked for them, with the parameters specified. The -t switch specified tunnel mode (you will want to use this), and the -r switch sets the virtual root for repositories served by svnserve, which means you don’t have to specify a full filesystem path to the repository. On my server, all my repositories are under /var/repos, so adjust this for your system configuration. The no-port-forwarding option instructs the ssh daemon to reject and port forwarding requests, and prevents the client tunnelling to any other ports - see the sshd man page for more information.

Now we need to configure the Subversion client to use this private key when accessing the repository. This is achieved by setting the SVN_SSH environment variable. You will probably want to add the following to your ~/.bash_history file so it is run every time you log in.

$ export SVN_SSH="ssh -i /home/user/.ssh/svn_user"

And that should be everything complete!

The same process can be used under Windows - I use TortoiseSVN as a client most of the time - you can generate a key pair using PuTTYgen in a similar way and copy the public portion to the ~/.ssh/authorized_keys file. Configure TortoiseSVN to use the key - right-click in Windows Explorer and choose TortoiseSVN > Settings - on the Network page, under SSH Client specify TortoisePlink.exe (normally foudn in “C:\Program Files\TortoiseSVN\bin” - you will want to use the -l parameter to specify the username and the -i parameter to specify the location of your private key - run TortoisePlink.exe without any arguments to see a list of options. Pageant is a nice key agent so you don’t have to enter your key passphrase every time.

Some useful information, in particular on using a single unix account for multiple Subversion users, can be found in the ssh-tricks file on collab.net.

No Comments, Comment or Ping

Reply to “Public key authentication when tunnelling Subversion repository access over SSH”