The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Поиск:  Каталог документации

Next Previous Contents

11. Remote, Multi-User CVS Repository

The Cederqvist manual at 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 and in the search box enter "ssh". Or visit and in the search box enter "ssh". Download and install the ssh RPM and then configure CVS to use it. See also

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

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/ (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 ( for ssh 1 or for ssh 2) to the server using secure copy (a part of ssh):

ssh 1: 
clientbox$ scp .ssh/

ssh 2: 
clientbox$ scp .ssh/

Then log onto the server and fix the authorized_keys file.

ssh 1: 
clientbox$ ssh
serverbox$ cd .ssh
serverbox$ cat >> authorized_keys

ssh 2: 
clientbox$ ssh
serverbox$ cd .ssh
serverbox$ cat >> 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

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.

11.2 Securing CVS by pserver Port Forwarding using an SSH Tunnel

From :

The Concurrent Versions System, in its "pserver" client/server mode, and secured by "ssh" encrypted tunnels, can allow multiple authors to safely collaborate over the internet. CVS is a source file version control system optimised for wide area networks, concurrent editing, and reuse of 3rd party source libraries. Pserver is a protocol used for communication between CVS clients and servers. SSH is a tool to transparently encrypt TCP/IP network connections. MSWindows users can use a posix shell

The tools discussed here are most functional in a unix environment but windows users can obtain similar functions by using a posix shell available from which will include an openssh package in 'latest' and a cvs package in 'contrib'. Other native windows ports of the tools are available but may lack needed features such as SSH2 DSA support. Creating the CVS Repository on the repository server machine

If you are a contributing author, you don't need to know how the repository was created. You may skip this section. If you are the unix repository administrator, you would create a directory and run cvs init then adjust the control files in CVSROOT to suit the permitted users (writers, passwd). It is convenient to have all files owned by "cvsuser" Starting the repository service

If you are a contributing author, you don't need to know how the repository server is started. You may skip this section. If you are the unix repository administrator, you allow the server to be started by xinetd with security constraints that specify that only clients local to the server machine may connect. To do this, create a configuration file named "/etc/xinetd.d/cvspserver" with contents similar to:

service cvspserver
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = cvsuser
        server          = /usr/bin/cvs
        server_args     = -f --allow-root=/cycomcvs pserver
        passenv         =
        log_on_failure  += USERID
        only_from               =
        bind                    =

then restart the xinetd super-service. Generating a public/private DSA keypair on the author's client machine

Contributing authors must perform this step only once. The "ssh" tools have various ways of authenticating users. The method chosen here is to use the DSA Digital Signature Algorithm. This is a public/private keypair algorithm which means that the secret private key need never be communicated to anyone and can stay safe on the clients hard disk (protected by a passphrase). The public key can be advertised to anyone with no loss of security. If you do not already have the ssh tools then you should obtain them from They must support SSH2 as we use the DSA algorithm not RSA.

A unix client will generate the keypair using:- ssh-keygen -d This will result in the creation of a file " /.ssh/". You must send this public file to the unix repository administrator. Do not send any other file nor reveal any passphrase. Authorizing a client to tunnel to the repository server machine

If you are a contributing author, you don't need to know how authorization is allowed. You may skip this section. If you are the unix repository administrator, on receipt of a clients "" file, append the single line therein to the " cvsnobody/.ssh/authorized_keys2" file on the server. Creating the secure tunnel between author's client machine and the repository server machine.

CVS keeps a single copy of the master sources called a source repository. Remote authors access the repository using CVS client programs which talk to the repository service using a "pserver" protocol and connect using a registered TCP/IP port (port 2401).

The pserver protocol is insecure because passwords are transmitted unencrypted and there are often some hacked hosts on a network that are sniffing for passwords. The connection to be used for the pserver protocol therefore needs to be encrypted where it passes over any network. The "ssh" suite of programs provides such encrypted connections.

SSH will create a secure tunnel which makes the repository service appear to be local to your client machine. Similarly, your client machine will appear to be local to the repository service. Both client and server are fooled into thinking that they are on the same machine and that no traffic travels over any network.

The single line unix command to achieve this is:- /usr/bin/ssh -v -a -e none -N -o 'KeepAlive=yes' -o 'BatchMode=yes' -L 2401:localhost:2401 The fixed cvsnobody user is just for ssh tunneling purposes; it is not relevant to CVS. The is the repository server machine name. This command will block. To destroy the tunnel, cntrl-c the command. If the tunnel collapses in use, reestablish it by repeating the command. Use another window to operate the CVS clients. Operating CVS clients on the author's client machine

Having established a tunnel, the remote CVS repository service now appears to be local to your client machine (i.e. at localhost). The CVS client programs obtain configuration data from a CVSROOT environment variable which should be set in unix (e.g in your ".bash_profile") using:-

export CVSROOT

The username "jsharp" and the repository root "/cycomcvs" will have been sent to you by the repository administrator.

The first CVS client command should always be:- cvs login You will be prompted for a password (again sent to you by the repository administrator).

To create a new cvs working directory and populate it from Honest John Car Rental Demo sources, use :-

mkdir mywork
cd mywork
cvs co hjvh
cvs co hjvhear
cvs co hjvhmodel

To freshen an existing working directory with updates from other authors, use:-

cd mywork/hjvh
cvs update

To publish the files that you have changed in an existing working directory, use:-

cd mywork/hjvh
cvs commit

To publish a newly created file in an existing working directory, use:-

cd mywork/hjvh
cd mywork/hjvh
cvs add mynewfile.txt
cvs commit

To import a new independent directory tree of sources into the repository, make sure all files in the tree are useful source and then use:-

cd projdir
cvs import projdir projV1_1 proj_V1_1
cd ..
mv projdir origprojsources
cvs co projdir

11.3 An Example - Access Remote CVS Server

To access a remote cvs server, here is an example:

# Set env variable
export EDITOR=/bin/vi

# Login to remote cvs server
cvs -d $CVSROOT login

# Goto some local directory
cd $HOME/<somedirectory>

# You MUST create a new directory, as below... 
mkdir cvsroot   # Create the local cvs directory which has the same name as in CVSROOT 

# Now get the files from remote CVS repository
cd cvsroot 
cvs get LDP/howto   # Or you can do 'cvs get . ' which will get everything

# After you make changes some file and later check-in that do
cd $HOME/<somedirectory>/cvsroot
cvs ci -m "your update comments here" LDP/howto/

Next Previous Contents

Inferno Solutions
Hosting by

Закладки на сайте
Проследить за страницей
Created 1996-2023 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру