ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


FreeBSD Basics

Accessing Secure Subversion Servers

by Dru Lavigne
08/11/2005

In the previous article, I demonstrated how to install Subversion and set up a shared data repository. This article shows how to access and use the repository using both the command line and a GUI.

Starting the Server

Because I use SSH for authentication, I first needed to start the svn server in tunnel (-t) mode on the system hosting the repository. I could simply type this as the user svn:

% svnserve -t

However, that user would lose his prompt. You might be thinking, do this instead:

% svnserve -t &

to start the service in the background. That is better; however, the service is still attached to svn's shell, so the service will stop abruptly if that shell ever closes. In this case, it is better to write a small shell script owned by the user svn. I saved mine as /usr/local/home/svn/repository/conf/svnserve.sh:

#!/bin/sh
#script to start svn server in tunnel mode
#first, set correct umask
umask 007
#then, use nohup to prevent program from closing if starting shell closes,
#send standard output and error to the bit bucket,
#and start in the background (to get prompt back)
nohup /usr/local/sbin/svnserve -t 2>&1 > /dev/null&

Don't forget to make the script executable and to double-check the permissions and ownership:

% chmod u+x ~svn/repository/conf/svnserve.sh
% ls -l ~svn/repository/conf/svnserve.sh
-rwxr--r-- 1 svn svn 112 Apr 29 09:36 /usr/home/svn/repository/conf/svnserve.sh

Then, as the user svn, run the script to start the service:

% ~svn/repository/conf/svnserve.sh

Simplifying User Authentication

Unless you configure a mechanism to cache your users' credentials, they will receive authentication prompts every time they view or make a change to the repository. Constant reauthentication can become very irritating very quickly.

Because I'm using the svn+ssh access method, I chose to implement public key authentication and use keychain to prevent the user from having to constantly retype in their passphrase. (Read more about this process at the IBM Developerworks article OpenSSH Key Management, part 2, which introduced this utility.)

Here are the steps I used for the user devel1 who uses FreeBSD as his desktop. First, I had him generate a public/private key pair using RSA as the type (-t) of algorithm. (If you're rusty on encryption algorithms, you may wish to read through Cryptographic Terminology 101 first.)

% ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key 
   (/home/devel1/.ssh/id_rsa): /usr/home/devel1/.ssh/id_rsa
Enter passphrase (empty for no passphrase): type something long but memorable 
Enter same passphrase again:
Your identification has been saved in /usr/home/devel1/.ssh/id_rsa.
Your public key has been saved in /usr/home/devel1/.ssh/id_rsa.pub.
The key fingerprint is:
f6:c2:51:ae:5c:17:91:57:53:c4:58:86:3f:5f:9a devel1@hostname.com

I then had devel1 copy over his new public key to his home directory on the system hosting the repository; in this case, 10.1.1.1:

% scp ~/.ssh/id_rsa.pub 10.1.1.1:/usr/home/devel1/.ssh

Note: When you do this, make sure you copy over the key with the .pub extension!

Before you can use that key, you have to append it to a file called authorized_keys. This will require one last ssh into the repository system using devel1's username and password:

% ssh 10.1.1.1
(login using password as usual)

% cd ~/.ssh
% cat id_rsa.pub >> authorized_keys
% exit

Finally, I had devel1 verify that SSH was using his public key for authentication:

% ssh 10.1.1.1

This time, instead prompting him for his password, it prompted for his passphrase:

Enter passphrase for key '/home/devel1/.ssh/id_rsa':
% exit

Now that the public key works on the repository system, it's time to deal with the private key. On devel1's PC:

% ssh-add ~/.ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)

Finally, I set up keychain to cache the credentials. As superuser on devel1's system:

# pkg_add -r keychain

Then, I had devel1 add these lines to his ~/.cshrc file:

`eval ssh-agent`
/usr/local/bin/keychain /usr/home/devel1/.ssh/id_rsa
source /usr/home/devel1/.ssh-agent > /dev/null

and inform csh about the change:

% source ~/.cshrc
KeyChain 2.5.3.1; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL

 * Initializing /home/devel1/.keychain/hostname.org-csh file...
 * Adding 1 ssh key(s)...
Enter passphrase for /usr/home/devel1/.ssh/id_rsa:
 * Identity added: /usr/home/devel1/.ssh/id_rsa (/usr/home/devel1/.ssh/id_rsa)

devel1 entered his passphrase. Now, he will see no prompts for any credentials for the entirety of his session as "keychain" will inform the SSH server that the identity has not changed.

Note: If your users instead use the bash shell, the DeveloperWorks article has the lines required for .bash_profile.

Pages: 1, 2, 3

Next Pagearrow





Sponsored by: