Getting subversion svn+ssh:// to work with PuTTY

Now I initially tried doing all this with PuTTY and pageant, and any tips on how to get it working would be appreciated.

I wanted to use subversion and host the repository on my hosted site, but running the dedicated server, or the running it thought WebDAV are basically out of the question. The dedicated server isn't allowed by policy and while Michal, the owner of cornerhost is a great guy and probably would have worked with me to get the WebDAV server up and running, I didn't want to tie up his and my time setting it up. I had seen people with root on their own machine spend quite a bit of time setting up subversion and WebDAV.

Now this didn't leave me out in the cold, I can still try, try being the optional word, using the svn+ssh:// option. This requires no long running services or extra ports, it just tunnels svn over ssh, which fits in the guidelines of my hosting provider. Now since I already have PuTTY setup on my client I should just be able to edit the local subversion config config file and tell it to use plink instead of ssh:


But lo, it was not to be. I kept getting svn: Connection closed unexpectedly. A little bit of debugging and I found the problem. Subversion starts plink/ssh and has it start with the command 'svnserve -t'. When plink or ssh is given a command to execute, the sshd server doesn't start a shell, instead it tries to run the command directly. But, without running the shell, my PATH on my server won't be setup correctly, and since I have installed subversion locally, the executable isn't found and the plink/ssh fails.

Now I thought I had a solution when I read about sshd's support for the ~/.ssh/environment file. This is a file that is filled with environment variables to be set for any running command. But lo, it was not to be either, the default setting for sshd are to not process that file.

Finally, I discovered that ssh does allow you to add in options for each key in ~/.ssh/authorized_keys, and one of those options is a program to run no matter what, over-riding whatever is sent by the client as a program to run. So I had my solution, create a new key, and have that new key always run 'svnserve -t'. Which is exactly what I did, adding the following line to my ~/.ssh/authorized_keys:

command="/home/myusername/bin/svnserve -t" ssh-dss AAAA.......

Now when I connected in from the client with pageant only loaded with my new key everything worked:

svn list svn+ssh://

Note the caveat, with only the new key loaded. Once I load up both my keys into pageant the old breakage comes back. That's because pageant tries every key in turn, and ended up picking the old one first. Setting up a Saved Session, and specifying the "Private key for authentication" didn't work either, I believe that's because the availability of pageant keys trumps this setting, but of that I am not sure.

In the end the solution was to break up the responsibilities, I use PuTTY for all my interactive shells, and for subversion I use the 'ssh' that comes with cygwin. This has the added benefit of not requiring any tweaking of the subversion config file. Still, I would like to know if I missed anything in my setup of PuTTY that would have allowed me to use it for both terminal sessions and for subversion. Any advice would be appreciated.

The readers digest version

On the client from which you will be ssh'ing:

$ ssh-keygen -t dsa -f mykey
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in mykey.
Your public key has been saved in

Move mykey to ~/.ssh/id_dsa for the client.

Copy onto the server that is hosting subversion. Append the value of to ~/.ssh/authorized_keys. Be sure to pre-pend the line with a command="" statement that calls up svn:

command="/home/jcgregorio/bin/svnserve -t" ssh-dss AAA...

To test your configuration, ssh into the server from the client. You should see:

$ ssh
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
Connection to closed.

The readers digest version for multiple logins from ssh

Here is an updated method from Mark Pilgrim:

The problem we're tying to solve here is that if you configure ssh as we have done above then everytime you ssh into that server you end up in subversion. That's not very helpful if you want to get to a bash shell.

The solution starts with creating a sub-domain for the host you want to access. In this case I'll create a sub-domain of I have a great hosting provider that let's me do this myself from a web based control panel. After creating the sub-domain you add some lines to your ssh config file on the client to select which key to use based on the domain name:

$ cat ~/.shh/config
  IdentityFile ~/.ssh/id_dsa
  IdentityFile ~/.ssh/id_dsa_bash

Now just refer to you subversion server using the sub-domain name and the key for subversion will be used. Ssh to the main domain name and the key for bash will be used.

Why don't you ask Michal to install Subversion so you don't have to rely on your local install? When I asked him why Vim wasn't installed, he put it on all the servers.

I've recently switched from cornerhost to because they offer User-mode Linux accounts. Michal was awesome but not having root access was disheartening. Setting up Apache2 and Subversion was a breeze with Debian.

Posted by Jason Diamond on 2004-03-12

Why not just update $PATH in you .bash_profile (or some such)?

It gets executed even when you do scp.  Here's what happens after I put "echo HEY" at the end of my .bashrc:

  $ scp b

(scp quits working since they "HEY" confuses it.)

Posted by Mark A. Hershberger on 2004-05-28

According to the SVN faq:

It says that SSH ignores anything in the .bash_profile. So adding stuff there, won't work.

And, I know from experience. I have the svnserve in my path. but I still can't use the svn+ssh.

Posted by Christopher Cotton on 2005-08-04

In my installation svnserve is in /usr/local/bin which seems not to be in the ssh path. Creating a symbolic link in /usr/bin to svnserve solves the problem because /usr/bin is in the ssh path.
After doing this svn+ssh:// works fine.

Posted by Markus on 2005-10-18

ha ha ha milex irc .network ss

Posted by anonymous on 2005-10-31