Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

September 26, 2007

svn+ssh:// and svnX

As I mentioned earlier, I recently got myself a RubyForge account, so that I could commit some critical security fixes to the main branch of Instiki.

RubyForge uses svn+ssh:// for developer access to their SVN repositories. So I went off in search of instructions for using svn+ssh:// with my favourite GUI SVN client, svnX. Unfortunately, all of the advice I found on the web was either overly-complicated or wrong (or both). So, herewith, are my notes for setting up svn+ssh:// access to RubyForge or other, similar, services.

First, let’s create a new SSH key-pair for ourselves, one which we will use exclusively with RubyForge.

  % ssh-keygen -t rsa1 -f /Users/yourname/.ssh/rubyforge

and hit return 3 times, creating a key-pair without passphrase protection. “No passphrase?!” I hear you cry. Yes, I know. This is necessary. The secret key is, nominally, only readable by you and we minimize the possible fallout should someone nonetheless manage to compromise it by using this key-pair only with this one service.

Note, also, the “-t rsa1”. RubyForge uses the SSH level-1 protocol, so we need to create a key-pair in a compatible format. For most other services, this option (and the “Protocol=...” line, below) can be omitted.

Now we upload the file ~/.ssh/rubyforge.pub on their web form, and wait a while.

In the meantime, let’s edit ~/.ssh/config and add the lines

  Host = rubyforge.org
  Protocol = 1
  IdentityFile = /Users/yourname/.ssh/rubyforge

to the end of the file.

We should be able to come back later and do an

  % ssh rubyforge.org

and login (and be immediately logged out) without being prompted for a password. Good.

Similarly

 % svn list svn+ssh://rubyforge.org/var/svn/yourproject

should also work without being prompted for a password.

Finally, in svnX, we add an new repository with the above URL as its path, and with the User and Password fields left blank.

And. It. Just. Works.

(Here’s where it was important to create the key-pair without a passphrase. svnX has no way to prompt you for a passphrase, so the public key authentication would fail, if we actually needed to enter one.)

The same technique (modulo the bit about the level-1 Protocol) should work with other svn+ssh:// services.

Posted by distler at September 26, 2007 11:20 PM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/1440



3 Comments & 0 Trackbacks

Re: svn+ssh:// and svnX

When I use svn+ssh, I avoid the need to enter a passphrase by running an ssh agent and registering the identity with “ssh-add”.

I know that I’ve seen graphical ssh agent programs for the Mac, but I just use the built in one directly using the technique described on this site (including the improved syntax from comment #2). Once it’s set up, you just need to run “ssh-add” from a Terminal window once and then you’re set until your next full shutdown.

Posted by: Steuard on September 27, 2007 10:49 AM | Permalink | Reply to this

Re: svn+ssh:// and svnX

I see.

Setting SSH_AUTH_SOCK in ~/.MacOSX/environment.plist is the required trick for allowing Aqua applications (in this case, svnX) to use the ssh-agent you started at the commandline in some terminal session. Normally, that ssh-agent would only be available to descendents of the terminal session in question.

The downside is that you now have a long-running ssh-agent process, listening on a known socket, and anyone who gains access to your account can freely use it. Arguably, that’s a little better than what I did (anyone who gains access to your account can read the secret key associated to the service in question), but not much.

The comments about Protocol level-1 still apply to the case of rubyforge, though. And, whether or not you’re using ssh-agent, creating separate key for the service (and configuring ssh to use it) is a sound idea.

Posted by: Jacques Distler on September 27, 2007 11:32 AM | Permalink | PGP Sig | Reply to this

Re: svn+ssh:// and svnX

SSH1 is completely broken and should not be used by anyone.

SSH2 allows something called connection multiplexing, which eliminates this problem completely and creates faster session startup. You have to add some goop to ~/.ssh/config, though:

host rubyforge.org
ControlMaster auto
ControlPath ~/.ssh/rubyforge-sock

then ssh in once, leave that connection open, and all later attempts to ssh in will re-use that open connection. It’s awesome.

But of course, it requires ssh2. just like being secure does. ssh1 should not be used by anybody.

Posted by: dbt on September 27, 2007 12:58 PM | Permalink | Reply to this

Post a New Comment