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:
[tunnels]
ssh=plink
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://myusername@bitworking.org/home/myusername/archives/test
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 mykey.pub.
Move mykey
to ~/.ssh/id_dsa
for the client.
Copy mykey.pub onto the server that is hosting
subversion. Append the value of mykey.pub
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 username@servername.org
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
Connection to servername.org 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 svn.bitworking.org sub-domain of bitworking.org. 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
Host svn.bitworking.org
IdentityFile ~/.ssh/id_dsa
Host bitworking.org
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 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 superman.everybody.org:.bashrc b
HEY
$
(scp quits working since they "HEY" confuses it.)
Posted by Mark A. Hershberger on 2004-05-28
According to the SVN faq:
http://subversion.tigris.org/faq.html#ssh-svnserve-location
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
After doing this svn+ssh:// works fine.
Posted by Markus on 2005-10-18
Posted by anonymous on 2005-10-31
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 tektonic.net 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