Next Previous Contents

11. Multi-User CVS Remote Repository

The Cederqvist manual at http://cvshome.org/docs/manual/cvs_2.html#SEC30 describes how to setup CVS for external access.

In order to use CVS for a group, one has to set up a permissions system to allow people to access the system from other machines. There are three ways to do this (:server:, :pserver:, and :ext:). The pserver mechanism and use of rsh are both insecure. Only the :ext: (with ssh) offers sufficient security protection.

If you set CVS_RSH to SSH or some other rsh replacement, the instructions may be similar to `.rhosts' but consult the documentation for your rsh replacement.

To get ssh visit http://rpmfind.net and in the search box enter "ssh". Or visit http://www.redhat.com/apps/download and in the search box enter "ssh". Download and install the ssh RPM and then configure CVS to use it. See also http://www.ssh.org.

Note: If you plan to configure CVS for use with rsh then you MUST do this critical step:


bash# chmod 600 .rhosts

See also JA-SIG UPortal CVS repository http://www.mis3.udel.edu/~jlaker/development.

11.1 SSH Authentication

If you're tired of entering passwords for each simple CVS command, then you can distribute your ssh-identity from the client to the server in order to allow automatic identification (i.e. no password needed!), this can be done by On the CVS server box do:


For ssh 1: 
bash$ cd $HOME
bash$ ssh-keygen

For ssh 2: 
bash$ cd $HOME
bash$ ssh-keygen -t rsa

You should be asked to save 'your identification' in /home/developer/.ssh/identity (ssh 1) or /home/developer/.ssh/id_rsa.pub (ssh 2) (or wherever $HOME points to), just hit enter. When asked for password and confirmation of password, continue hitting enter. Then copy your public key (identity.pub for ssh 1 or id_rsa.pub for ssh 2) to the server using secure copy (a part of ssh):


ssh 1: 
clientbox$ scp .ssh/identity.pub developer@serverbox.domain.com:~/.ssh

ssh 2: 
clientbox$ scp .ssh/id_rsa.pub developer@serverbox.domain.com:~/.ssh

Then log onto the server and fix the authorized_keys file.


ssh 1: 
clientbox$ ssh developer@serverbox.domain.com
serverbox$ cd .ssh
serverbox$ cat identity.pub >> authorized_keys

ssh 2: 
clientbox$ ssh developer@serverbox.domain.com
serverbox$ cd .ssh
serverbox$ cat id_rsa.pub >> authorized_keys2
serverbox$ chmod go-w authorized_keys2

You should now be able to ssh directly from the client to server without having to enter password, this can be tested with:


ssh 1 or ssh 2: 
clientbox$ ssh developer@serverbox.domain.com

Version control from this point should not require you to enter the password.

Note: This enables anyone getting access to your client to continue into the server without knowing the password on the server.

Encrypted Disks

If you fear such a situation, this can (somewhat) be prevented by using a encrypted disk, e.g. PGPDisk holding the $HOME directory on the client. So when an intruder takes over your machine s/he needs to know the password for your encrypted disk in order to get further into the server. Another advantage of using a encrypted disk is that your (checked out) source code can reside on it.


Next Previous Contents