[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SSH svnserver under windows?

From: Gili <junk_at_bbs.darktech.org>
Date: 2004-11-28 02:28:11 CET

        Here is how instructions on how to make svn+ssh work under the Tortoise client with the server having a root
directory. All this under win32 and assuming the client and server are on the same machine but it should be easy to
fix the documentation so the server/client reside on different machines. Please discuss this sort of configuration
in the official documentation. The instructions are:

1) Install the "OpenSSH" and "keychain" packages from cygwin.
1a) Cygwin can be found here: http://www.cygwin.com/
1b) Instructions for configuring the OpenSSH server can be found here: http://pigtail.net/LRP/printsrv/cygwin-
sshd.html

2) Use this page as a template for creating your public/key SSH keys for Subversion:
http://odin.himinbi.org/subversion_shared_repository.html

3) In the cygwin shell, run "keychain .ssh/subversion.key"
4) Copy .ssh/subversion.key.pub .keychain<hsotname>.sh.pub
5) Copy .ssh/subversion.key.pub .keychain<hsotname>.csh.pub
5) "keychain .keychain/<hostname>.sh"
6) chmod u+x .keychain<hostname>.sh
7) Create ~/subversion.bat with the following contents:

<cygwin_path>\bin\bash.exe --login -c "cd ~; .keychain/<hostname>-sh; ssh -i .ssh/subversion.key %1"

8) Go into TortoiseSVN -> Properties -> Network -> SSH client: "<cygwin_path>\home\<your username>\subversion.bat"

        Anyway, in essense what this does is everytime TortoiseSVN tries to connect to the server via SSH, it runs
subversion.bat. This connects to the server using your public key and invokes the command you configured in step 2.
Everything should work as expected.

Gili

On Sat, 27 Nov 2004 18:39:33 -0500, Gili wrote:

> I see. But this requires a lot of configuration on the client-end I'd like to avoid. They should just be able
>to open up their favorite Subversion client, plug in a URL and away they go. Requiring them to change
configuration
>all over their machine plus to be sure to manually startup a SSH tunnel from their end ... that's all too much.

> I wish svn+ssh:// would just work :)

>Gili

>On Sat, 27 Nov 2004 18:23:44 -0500, Scott Palmer wrote:

>>That's what I'm talking about. Using SSH to open a tunnel to port 3690
>>on the server machine.

>>Scott

>>On Nov 27, 2004, at 5:46 PM, Gili wrote:

>>>
>>> I need encryption though, hence SSH.
>>>
>>> Gili
>>>
>>> On Sat, 27 Nov 2004 17:37:19 -0500, Scott Palmer wrote:
>>>
>>>> I just use regular svn: protocol through a tunnel to the real svn
>>>> server.
>>>
>>>> Just setup a tunnel to your svn server machine port 3690. then
>>>> pretend
>>>> the repository is localhost. I also add an entry to my hosts file so
>>>> that the name of the server is also resolved to local host. So
>>>> svn:externals works as expected.
>>>
>>>> The svn+ssh protocol is weird. I think it runs a svnserve instance on
>>>> the machine that you have connected the tunnel to as the user you have
>>>> connected as... anyway I found it thoroughly confusing and went for
>>>> the
>>>> straight-forward method of tunneling port 3690.
>>>
>>>> Scott
>>>
>>>> On Nov 27, 2004, at 5:24 PM, Gili wrote:
>>>
>>>>>
>>>>> Ok, I'm still confused. Who is actually responsible for running
>>>>> svnserve? Does the SSH user log in, run
>>>>> "svnserve -t" himself and then proceeds to interact with the server?
>>>>> Who shuts down the server? How? (I see no way
>>>>> to shutdown the server if each user spawns his own) Someone please
>>>>> point me in the right direction.
>>>>>
>>>>> Thank you,
>>>>> Gili
>>>
>>>
>>>
>>>
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Nov 28 02:30:38 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.