The Artima Developer Community
Sponsored Link

Java Buzz Forum
Subversion / TortoiseSVN SSH HowTo

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Marc Logemann

Posts: 594
Nickname: loge
Registered: Sep, 2002

Marc Logemann is founder of www.logentis.de a Java consultancy
Subversion / TortoiseSVN SSH HowTo Posted: Oct 14, 2004 7:18 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Marc Logemann.
Original Post: Subversion / TortoiseSVN SSH HowTo
Feed Title: Marc's Java Blog
Feed URL: http://www.logemann.org/day/index_java.xml
Feed Description: Java related topics for all major areas. So you will see J2ME, J2SE and J2EE issues here.
Latest Java Buzz Posts
Latest Java Buzz Posts by Marc Logemann
Latest Posts From Marc's Java Blog

Advertisement

=======================================================
Subversion/TortoiseSVN SSH HowTo (Windows -> Linux)
=======================================================
(revision 0.5 by (c) Marc Logemann)

Because many new subversion users run into problems when attempting to use subversion with SSH, i compiled a HowTo for that issue. Perhaps i will expand this HowTo later on and submit it to the subversion or torteoiseSVN docs.

-------------------------
Our Scenario:
-------------------------
Server: Linux or unix like system
Client: Windows 2000/XP (or variant)

-----------------------------------------
Installing subversion (server)
-----------------------------------------
I wont go into details here, because this topic is covered in great length in the oficial subversion documentation. But one thing i want to point out nevertheless. If you compile subversion from source and dont provide any argument to ./configure, Subversion creates a "bin" directory under /usr/local and places its binaries there. This is no problem as long as you run subversion as daemon, but if you want to use tunneling mode with SSH, you have to be aware that the user logging into via SSH can execute the svnserve program and some other binaries. For this reason, either place /usr/local/bin into the PATH variable or create symlinks of your binaries to the /usr/sbin directory or any other directory which is commonly in the PATH.

To make sure that everything is ok. Login in with SSH and the target user to the system later on and type: "which svnserve". This command should tell you if svnserve is reachable.

Furthermore this document assumes that you allready have a subversion repository created with "svnadmin create". Please pay attention to the ACL of the repository in order to reduce possible problems. Check that each user coming in via SSH has apropriate rights to work with the repository.

------------------------------------------------
OpenSSH and certificates (server)
------------------------------------------------
Again i wont go into details about OpenSSH installation, this is covered elsewhere better. But on most systems, enabling SSH is just a matter of installing a RPM. If you rent a pre-installed linux server from a hosting company, SSH is most likely allready installed. To be sure everything is in place, type: "ps xa | grep sshd" and watch out for SSH jobs.

Assuming OpenSSH is installed, one of the most important steps is to create a keypair for authentication. There are two possible ways of creating the keys. The first way is to create the keys with puttygen (a program of the putty family), upload the public key to your server and use the private key with putty. Because of some problems with this approach, i prefer the other way. This way creates the keypair with the OpenSSH tool ssh-keygen and download the private key to your client and convert the private key to a putty-style private key.

Lets do this step by step:

- login to your server
- type: ssh-keygen -b 1024 -t dsa -N passphrase -f mykey
- change "passphrase" to a secret keyword only you know
- type: ls -l mykey*

We just created a SSH2 DSA key with 1024 bit keyphrase. You will see two files. One named "mykey" and one named "mykey.pub". As you might guess, the .pub file is the public key file, the other is the private one. Next create a user on the server with a home directory:

- type: useradd -m myuser

You will have a directory under /home with the name "myuser", create a new directory in "myuser" called ".ssh":

- type: cd /home/myuser
- type: mkdir .ssh

Then go to the directory where you created your keys and copy the public key to the .ssh userfolder with the following command:

- type: cp mykey.pub /home/myuser/.ssh/authorized_keys

Please pay attention to the filename, it really must be "authorized_keys". In some old OpenSSH implementations, it was "authorized_keys2". Now download the private key file to your client computer. Remeber, the file was "mykey"

------------------------------------------------------------
SSH key generation and connection check (client)
------------------------------------------------------------
Grab the tools we need for doing SSH on windows on this site:
http://www.chiark.greenend.org.uk/~sgtatham/putty/

Just go to the download section and get "Putty", "Plink", "Pageant" and "Puttygen"

In order to use the private key we get from the server, we have to convert it to a putty format. This is because the private key file format is not specified by some standard body. To do this we simple open "puttygen" and open the "conversions" menu and chose "Import Key". Then browse to your file "mykey" which you got from the server enter your provided passphrase upon creation of the key. Finally click "Save private key" and save the file as "mykey.PPK" somewhere on disk.

Now we are ready to use this key for the first time to test the connection. In order to do this, we open the program "putty" and create a new session like this:

Session->HostName: Hostname or IP Adress of your server
Session->Protocol: SSH
Session->Saved Sessions: MyConnection
SSH->Prefered SSH Protocol version: 2
SSH->Auth->Private Key file for auth: $PATH$\mykey.PKK (replace $PATH$ with real path to the mykey.PKK file)

Then go back to Session tab and hit "save" button. You will see "MyConnection" in the list of available connections.

Next click "open" and you should see a telnet login prompt. Use "myuser" as username (without double quotes of course) and if everything is ok, you dont have to provide a password to your system. If the system still requires a password, something went wrong. See Debugging Section of this HowTo.


-----------------------------------------------
Testing SSH with TortoiseSVN (client)
-----------------------------------------------
After installing TortoiseSVN (http://tortoisesvn.tigris.org/download.html) right click on some folder inside your Windows Explorer. You will see a menu item called TortoiseSVN->RepoBrowser. After opening the browser you have to enter a URL like this:

svn+ssh://myuser@MyConnection/usr/local/repos

Lets talk briefly about the URL (if you need more infos, check the subversion docs). The Schema name is "svn+ssh", this tells Tortoise how to handle the requests to the server. After the double slashed, you can provide the user which is trying to connect to the server, in our case this is "myuser". After the "@", we supply our putty session name. This session name contains all details like where to find the private key and the servers IP or DNS. Last we have to provide the full path to the repository. Its assumed that a subversion repository resides at /usr/local/repos

If you submit the URL, you will see a opened tree on the next screen until the node "repos". Yet, there has not been made any connection, because the tree representation comes from the supplied URL. When you hit the "+" button in front of "repos", the connection will be established and you will see the "+" sign dissapearing if you dont have anything in the repository or you will see your allready imported projects and files.

Right now, you should have a running SSH Tunnel in conjunction with TortoiseSVN.

-----------------------------------------------
Configuration Variants (pagent)
-----------------------------------------------
Now i will continue to show some configuration variants, that can be helpful during everyday work.

One way to simplify the URL in TortoiseSVN is to set the user inside the putty session. For this you have to load your allready defined session "MyConnection" in putty make the following entry:

connection->Auto Login username: myuser

Then save your putty session as before and try the following URL inside Tortoise:
svn+ssh://MyConnection/usr/local/repos

This time we only provide the putty session "MyConnection" to the SSH client TortoiseSVN uses (TortoisePlink.exe). This client is capable of checking the session for all necessary details like loginuser oder server ip.

Some people like using pageant for storing all their keys and in fact each howto explains that its important to place your keys there. In fact, because a putty session is capable of storing a key, you dont need pageant for normal business. But imagine you want to store keys for several users, in that case, you would have to edit the putty session over and over again, depending on the user you are trying to connect with. For this situation pagent makes perfectly sense, because when putty, plink, tortoisePlink or any other putty-based tool is trying to connect to a SSH server, it checks all private keys that pageant carries to initiate the connection.

For this task, simply start pageant and add a key. It should be the same private key you defined in the putty session above. If you use pageant for private keys storage, you can delete the "SSH->Auth->Private Key file for auth" section inside your putty session. You can add more keys for other systems or other users of course. If you dont want to repeat this procedure after every reboot of your client, you should place the pageant in autostart group of your windows installation. You can append the keys with complete paths as command line arguments to pageant.exe

The last way to connect to a SSH server is by just using this URL inside TortoiseSVN:

svn+ssh://myuser@100.101.102.103/usr/local/repos

As you can see, we dont use a saved putty session but an IP address as connection target. We also supply the user, but you might ask how the private key file will be found. Because TortoisePlink.exe (the standard SSH client for TortoiseSVN) is a modified version of the plink tool from the putty suite, also TortoiseSVN looks for a running pageant and will try all the keys stored in pageant.


----------------------------------------
Debugging / Troubleshooting
----------------------------------------
Problem: I get "Unable to write to Standard output" when trying to make a connection with TortoiseSVN
Answer: The SSH daemon is most likey not able to find the svnserve binary. Login with your target user (here myuser) into the server and type "which svnserve". If you dont see the path to the binary, make this file (and most likely the other subversion binaries) globally accessible to this user.

Problem: I get: "No repository found in 'svn+ssh://myuser@100.101.102.103/usr/local/repo'
Answer: Check the path to your repository (here /usr/local/repo) if it really exists on the server and check the permissions on that folder and its contents.

Problem: I am getting the password dialog over and over again
Answer: TortoiseSVN (or better its SSH client TortoisePlink) cant find a key for the current user. Run pageant and add your private key or define a putty session with a private key included.


-------------------
Feedback
-------------------
For comments or corrections on this howto, please use the TortoiseSVN maillist on http://tortoisesvn.tigris.org/

Read: Subversion / TortoiseSVN SSH HowTo

Topic: Russell's Java 2SE 5 Complaints Previous Topic   Next Topic Topic: Lightweight containers vs. EJB: Don Box, Ted Neward, Rod Johnson, and more

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use