This file describes how to use the sshd "command" directive to set up svn+ssh with any or all of the following properties: (1) Specify a full path to the svnserve binary (2) Specify a repository root as one can with the svnserve daemon (3) Avoid giving full shell access to an svn user (4) Use a single Unix account for multiple svn users This file will assume that the server is using openssh on a Unix-like host. The same tricks may work for other server setups, but changes may need to be made to the details. These tricks require that you use public-key authentication; they will not work with password authentication. These tricks also assume that the client's key-pair is used only for access to svnserve; if you want to retain general shell access to the host, create a second, dedicated key-pair for Subversion access and (assuming a Unix client) set the environment variable SVN_SSH to "ssh -i /path/to/private/key/file". The basic idea -------------- To set up public key authentication on the server, you create a file $HOME/.ssh/authorized_keys, where $HOME is the home directory of the Unix account being used for svnserve on the server. Each line of the file is typically copied from a client's public key file, and looks something like: ssh-rsa AAAABlotsmoregookhere= address@example.com The first field specifies the type of the key, the second is the key itself in uuencoded format, and the third is a comment which humans can use to identify what the key is. In the future, we'll write these three fields as "TYPE KEY COMMENT" The basic trick, then, is to add a directive to this line telling sshd to ignore the client's specified command and run a different command instead. The line in the authorized_keys file will then look like: command="COMMAND" TYPE KEY COMMENT For svn+ssh access, the client generally specifies the command "svnserve -t"; the following tricks will modify the command in various ways. Trick #1: Specify a full path to the svnserve binary ---------------------------------------------------- For this trick, specify a command like: command="/full/path/to/svnserve -t" TYPE KEY COMMENT Trick #2: Specify a repository root ----------------------------------- For this trick, add a -r option to the svnserve command: command="svnserve -t -r /repository/root" TYPE KEY COMMENT Trick #3: Avoid giving full shell access to an svn user ------------------------------------------------------- For this trick, it isn't necessary to modify the command at all. We just need to make sure that the client doesn't run any other commands. However, you should also use the "no-port-forwarding" option to prevent the client from tunneling to other ports: command="svnserve -t",no-port-forwarding TYPE KEY COMMENT You may also wish to specify the options "no-pty", "no-agent-forwarding", and "no-X11-forwarding", just to give the client less wiggle room. Trick #4: Use a single Unix account for multiple svn users ---------------------------------------------------------- For this trick, establish a distinct key pair for each of the svn users, list all of the public keys in the authorized_users file, and specify the "--tunnel-user" directive in the command for each entry: command="svnserve -t --tunnel-user=alice" TYPE1 KEY1 COMMENT1 command="svnserve -t --tunnel-user=bob" TYPE2 KEY2 COMMENT2 As with trick #3, it may be wise to specify "no-port-forwarding" and perhaps the other restriction options to prevent the users from obtaining other kinds of access. The --tunnel-user option is new in svn 1.1.0, so this trick will not work if the server has svn 1.0.x. Combining the tricks -------------------- Here's an example of how you might combine all four tricks: command="/path/to/svnserve -t -r /repository/root --tunnel-user=alice",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty TYPE1 KEY1 COMMENT1 command="/path/to/svnserve -t -r /repository/root --tunnel-user=bob",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty TYPE2 KEY2 COMMENT2