Home | Stuff | Source Archives | Links | Time Wasting Links

Flexible RSH/SSH setup patch for CVS

This patch let's you specify the remote shell program to use on a per user@host basis. This makes it a lot easier to use separate private keys for each remote repository you connect to.

It helps solves a particular problem that we have in our multi-sited development group. That is, each of us use multiple repositories that are in different administrative domains. We don't trust the communications links between our sites and we don't run a VPN, so everything must be tunneled over an encrypted path. The repository admins don't want the users to be able to log in, so the path of least resistance is to use ssh with private key login, and a login shell which does not let you do anything but start cvs. We also use separate private key pairs for each repository we connect to, so we can't just leave a single private key in ~/.ssh/.identity.

All this adds up to a big pain with CVS. This patch let's you specify different remote shell programs (like ssh) and the options to feed them (like -i ~/.ssh/repos1_dsa ) on a per host basis.

Download cvs-easyssh.patch apply aginst the sources to cvs-1.12.9 and build.
Or download the fully patched sources.

How to use it

Add lines of the form

   tony@cvs.appletreegroup.com --rsh=/usr/bin/ssh --X=-i -X /home/tony/.ssh/ident2
   tony@cvs.ics.com --rsh=/usr/bin/ssh --X=-i -X /home/tony/.ssh/ident2

-r command

--rsh=command

Specify an alternate command rather than rsh (or whatever was specified during configure)

-X arg

--X=arg

Specify an additional argument to the command.

When CVS connects to the remote server it will match the user@host specified in CVSROOT against lines in ~/.cvsrc to select the right pairing of options. Using the example above, we would end up with different private key files being used for each of these two commands

   % cvs -d:ext:tony@cvs.appletreegroup.com:/repository co aproject
   % cvs -d:ext:tony@cvs.ics.com:/archive/cvs co anotherproject

The rationales for doing it this way, rather than extending the CVSROOT syntax are

1. On a large project, the documenation can specify the CVSROOT of the source, without specifying elements that would, by definition, vary per user (like the path to the identity file).
2. If a user changes their remote shell tool after checking out a repository, the do not have to edit every CVS/Root file.
3. It was less invasive than mucking with the CVSROOT parser.

The environment variable CVS_RSH takes precedence over lookups in the ~/.cvsrc file.

Why not support SSH directly?

I don't add specific support for SSH because it would not be much easier, and it would be less general.

Why not support SSL directly?

Really, the question is "Should CVS provide encrypted communications over SSL right out of the box, without having to use an external program?". The answer is, I think so, but it's not an easy job. Having added OpenSSL support to my HTTP protocol tool, I discovered a lot of issues about trust and certificates that would come into play. There is also the risk of opening up a brand new security hole.

If the CVS community decides it wants direct SSL support, I would be happy to try to add it just for the personal edification. If some corporation wants that before the community can come to consensus, I can quote you a price you will find attractive. Send mail to tony@aiu.to.

Further securing your repository

I access a few repositories that are totally locked down. No one is allowed to log in, and we all must connect via ssh with private keys (we don't even know our passwords). The script we run as your login shell is a simple perl one I snatched off the web.

Download cvssh.pl

Warnings

This has not been testing on Windows. It does not work on OS/2, because that code should get refactored rather than enhanced.

Licensing

I grant permission to distribute this patch under the terms of the GNU Public License

Tony Aiuto