Subversion via ssh using authorized_keys

When I used subversion in the past, I created a separate user on the Linux operating system. This user then got the right to login via ssh to use subversion. If you have one or two users to manage, this is not a big deal. Especially if you trust them with the shell access you are giving them, but when the number of users grows, management can get time-consuming, and you may want a better solution.

There are 2 options I have used so far. The first is to limit the user’s access to “svnserve” without giving real shell access. The second option is to create just one user for the SVN repository and just manage the access and authentication via the authorized_keys used to login. Neither option reuqires “svnserve” to run as a daemon on the server.

Limit user’s shell access to svnserve

When you create a new user on your linux server you can specify a shell. Usually this will be the shell you see after you successfully log in. Our goal is to not allow the user to interact with the server other then with the SVN server.

We need to limit the user’s access to the “svnserve” executable which is responsible for providing access to the SVN repositories, but if we just configured the “svnserve” executable as the login shell, accessing the repositories would be a little tricky.

Lets assume we have an SVN repository at /var/lib/svn/ and it is called “Test_Repo”. If we just configured the “svnserve” executable as the login shell, it does not work. This is because of two things: first, if you specify svserve as the login shell, the SVN client still tries to launch svnserve, which does not work as it is not a real shell. The second reason is that svnserve does not know where the repositories are located. So there is a trick.

We’ll create a script that will do exactly what we need. It will launch svnserve and make sure that the repository root is set correctly. To do this we need to locate the svnserve executable (use “which svnserve” for this). In my case it is at /usr/bin/svnserve. Now create a script at the location of your choice. Edit the script (I call it “svnserve.sh”) with your favourite editor and enter the following:

#!/bin/sh

# remove the svnserve executable name to get only the parameters
param=`echo "$@" | sed 's/^.*svnserve //'`

# execute the svnserve binary
exec /usr/bin/svnserve --root /var/lib/svn $param

After you have saved the script, make sure it is executable (“chmod a+x svnserve.sh”). This will do exactly what we need. As you can see from the comments above, it will take the parameters sent to svnserve and pass them on to the binary. With this trick we can now configure the “svnserve” as login shell and the user can only access the subversion repositories.

warningWith this solution, all users need write access to the subversion repository directory to be able to commit. The directory’s permission and owner must therefore match the user’s group to allow the required access.

Authenticate with SSH key

The concept of the second option is that you have one user with multiple authorized ssh keys. Each key identifies one user and also limits the user to svnserve. This is all done with the “command” option in the “authorized_keys” file. All the details about the possible options can be found at the man page of “sshd(8)“. If you want to know more about creating and using SSH keys, have a look at my SSH passwordless login with SSH key article. The format of the “authorized_keys” file is as follows:

options keytype base64-encoded-key comment

For this example I have shortened the key to make it easier to read it. The line for a user to only access the SVN reporitory would look like this:

command="/usr/bin/svnserve -r /var/svn -t --tunnel-user=svn-username",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AB3Nz...EN8w== key_name

The command will call the “svnserve” program with a couple of parameters. All the details about the options can be found on the man page of svnserve(8). The two most important are the “-r” option to define the location of the repositories (repository root) and the “–tunnel-user” option which defines the svn username to be used when this key is used to authenticate. This is also the user you will see when something is commited to the repository.

warningWhatever option you choose to authenticate via SSH, the permissions for the individual users to the svn repository still need to be configured in the repository configuration.

Conclusion

The second option is a similar approach to the first, but it is much easier to administrate. While the first option requires an individual Linux account for every user accessing the SVN repository, the second one needs just one user to be created. The file permissions of the SVN repositories can be much easier to administrate with just one Linux user accessing them, but you will still see the correct user names in SVN commit messages.


Read more of my posts on my blog at http://blog.tinned-software.net/.

This entry was posted in Linux Administration, Security, Version control system and tagged , , , . Bookmark the permalink.