Site Meter Amund Tveit's Minimal Guide to CVS with SSH
 

Home
Publications
Resume
Blog
InternetPercent
Amund@Twitter
Google
Web amundtveit.info

A Minimal Guide to CVS with SSH

Author: Amund Tveit, ae@amundtveit.info

This is a guide to using CVS (Concurrent Versions System) with SSH (Secure Shell) to enable efficient and secure version control for open source (or closed source) software development projects.

Source doesn't necessarily mean program code, but can also be documents (e.g. .doc, .xml, .fm, .pdf, .ps) or other binary/textual files (.xls, .vsd).

My usual server configuration is either using the SourceForge repository for open source projects, or a Unix box at my work or the University for commercial and private projects. For CVS/SSH client access I mostly use Windows with Cygwin. (note: 2001, at grad.school)

Prerequisites

This assumes that the CVS repository should be residing on the server, and the development on the client.

Server(s)

  1. Linux or another Unix operating system
  2. sshd running (Secure Shell Daemon)
  3. cvs installed

Client(s)

  1. Linux or another Unix operating system (or Cygwin for Windows)
  2. ssh installed*
  3. cvs installed*

User Account

  1. On client(s) - regular/no user (root/Administrator not required)
  2. On server - regular unix user (root not required)
(* Comes with Cygwin)

Commands that should be done on the server is are marked with serbox$ <command>, and correspondingly for the client devbox$ <command>.

Assume that the server is serbox.domain.com and one of the clients is devbox.domain.com. The developer has username developer on both the server and the client.

Initialize CVS Repository

On the server you need to do some preparations before the CVS repository can be used:
  serbox$ mkdir -p /usr/local/cvsrepository
  serbox$ export CVSROOT="/usr/local/cvsrepository"
  serbox$ cvs init
Then the repository should be avaible to use, but you need to set some environment variables at the client ($CVSROOT refers to the CVS repository, and $CVS_RSH refers to the communication protocol and medium)
  devbox$ export CVSROOT=":ext:developer@serbox.domain.com:/usr/local/cvsrepository"
  devbox$ export CVS_RSH="ssh"

Creating a CVS Project

Assuming that you have some files in a directory called YourProject that you would like to add to a project with the same name.
  devbox$ cd YourProject
  devbox$ cvs import -m "initial import of YourProject" YourProject myself start
(myself is the vendor tag, and start is the release tag)

Checking In/Out Files/Projects

To check out code from the repository do:
  devbox$ cvs checkout YourProject
To check in modifications (on existing files)
  devbox$ cvs commit
    Note: It's usually a very good idea to do cvs update before commiting changes

Adding/Removing Files

To add a new file to the repository do:
  devbox$ cvs add newFile
  devbox$ cvs commit
To add a new binary file to the repository do:
  devbox$ cvs add -kb newBinaryFile
  devbox$ cvs commit
(-kb specifies that file is binary)

To add a new directory to the repository do:

  devbox$ cvs add newDirectory
  devbox$ cvs commit

To remove an existing file from the repository do:

  devbox$ rm existingFile
  devbox$ cvs remove existingFile
  devbox$ cvs commit

Staying in sync with other developers

In order to receive changes from the latest commits from your peer developers, do:
  devbox$ cvs update
If another developer has done bigger changes such as adding new directories etc. do:
  devbox$ cvs update -d

Creating Releases

Since there usually are several files with different version numbers in a project, it's a good idea to "stamp" the files with a release tag for each release, this can be done like this (for version "v001"):
  devbox$ cvs tag -R "v001"
  devbox$ cvs commit
This release can be checked out with
  devbox$ cvs checkout -r "v001" YourProject 

Lazy, but convenient ssh authentication

If you're tired of entering passwords for each simple CVS command, please continue reading: 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

ssh 1:

  devbox$ cd $HOME
  devbox$ ssh-keygen

ssh 2:

p  devbox$ cd $HOME
  devbox$ 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:

  devbox$ scp .ssh/identity.pub developer@serbox.domain.com:~/.ssh

ssh 2:

  devbox$ scp .ssh/id_rsa.pub developer@serbox.domain.com:~/.ssh

Then log onto the server and fix the authorized_keys file.

ssh 1:

  devbox$ ssh developer@serbox.domain.com
  serbox$ cd .ssh
  serbox$ cat identity.pub >> authorized_keys

ssh 2:

  devbox$ ssh developer@serbox.domain.com
  serbox$ cd .ssh
  serbox$ cat id_rsa.pub >> authorized_keys2
  serbox$ 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:

  devbox$ ssh developer@serbox.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 the situation of someone taking over your computer, the risk can be (somewhat) reduced 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.

Academic/Educational Use of this Guide

  1. Scott B. Baden. CSE 131A Compiler Construction I, Department of Computer Science and Engineering, University of California in San Diego, USA, 2005

  2. Bart Dorlandt. CVS, Essential Skills for Administrators (Course), Dutch Master Education in System and Network Engineering, University of Amsterdam, The Netherlands, 2004

  3. Jim Willis. Overview of Development Environment, Rhode Island Secretary of State, Division of eGovernment and Information Technology, USA, 2004

  4. Chris Batten. "C/C++ Linux Development" (lecture), MASLAB (Mobile Autonomous Systems Laboratory), MIT, USA, 2003

  5. "Using CVS/SSH on Windows via Cygwin", Cybersecurity Classrom, Cyber and Homeland Security Research and Development, Institute for Security Technology Studies, Dartmouth College, USA

Other sources that refers to this guide

  1. Carsten Grohmann. "Sicheres CVS", Germany, 2003

  2. Maik Zemann. "CVS: The Open Standard for version control", Greifsteuerung fur antropomorphe Roboterhande, Germany, 2003

  3. James Knowles. "Using CVS on a Windows Client Over the Internet", IFM Services LLC, USA

  4. Documentation of CvsGui

Acknowledgments

Thanks to Eric Montagne and Derek Keeler for ssh 2 instructions.

Other CVS and SSH Resources

Feedback

Your feedback is greatly appreciated, please take your time filling out the form below so I can continue to improve this minimal guide.
This guide was:
    Just what I was looking for!
    Ok..
    Crappy!
Your email address:

Your suggested improvements:

Written by Amund Tveit, 2001-09-25, last updated 2001-09-25.

Follow @atbrox