Heilan' Coo :: MacCVSClient :: User Guide | |
MacCVSClient and SSH |
If you need to access CVS repositories over the internet with good security, you can use SSH encryption software as an intermediary between MacCVSClient and CVS server. To make all this work, you need to install an SSH server on the CVS server machine. Additionally, you need to set up an SSH client on your Macintosh. In the following, I will explain details about how to configure Mac OS based SSH clients so you can use them to access CVS servers. Information on how to get an SSH server installed and running on the CVS server is beyond this MacCVSClient manual. Please find out elsewhere; if you know a good source of information about this, please let me know and I'll link to it. |
SSH Clients on the Mac |
There is a good handful of SSH implementations on the Mac. For use with MacCVSClient, you need an SSH client that supports port tunneling. As far as I know, there are currently these SSH implementations available on the Mac that do support it (if I am missing some here, please let me know): F-Secure SSH by Data Fellows for the Mac is a commercial product; the evaluation version (1.0 Trial) that I tried supported SSH1 only. I understand there is a new version out by now that supports SSH2 only. I have never used it. Mindterm by Mindbright Software AS is a GPL'ed (and thus free) Java based SSH1 implementation. MacSSH by Jean-Pierre Stierlin is a GPL'ed SSH2 client. Mac OS based SSH implementations that currently can't be used and why not: NiftyTelnet SSH (as of 1.1 SSH r3) by Jonas Walldén does not support port tunneling and therefore can't be used for our purpose. |
Port Tunneling in SSH |
A way to use SSH is through "port tunneling". Here, your SSH on the Mac connects to the SSH on or near the CVS server. SSH can then pretend to offer services on the Mac side and not really offer these services but tunnel them through the SSH connection and connect to the service in question on the computer on the far side of the SSH connection. This way, our local end of the SSH connection "looks like" the server on the remote end of the SSH connection has on the other end (if we only take the tunneled ports into account). The connection is transparent, i.e. MacCVSClient will not know about it. The price you are paying for security is that the connection is slower than normal because the whole data stream is encrypted. |
Tunneling CVS |
Suppose, we want to use CVS in "pserver" mode with the CVS server running on machine "dodo" on port 2401 (the default port for pserver CVS). Say also we cannot connect directly because the CVS pserver service on "dodo" is not accessible securely from our machine (or not accessible at all, blocked for security reasons that is). Assume at last, that luckily, there is SSH running on "dodo" and you can connect to it with the chosen Mac implementation of SSH. Now you have to set up a "tunneled" port in SSH on our Mac. The remote host is "dodo", both local and remote ports are 2401. Note that you can choose any number you like for the local port. For simplicity's sake, let's use the standard one. It is crucial that you choose the proper remote port, though. Otherwise, you won't be able to connect to the CVS service on the remote server. After you have connected to the remote server with SSH and your port tunneling is running, you have to set up a new MacCVSClient Login Profile for this SSH connection. Here, you will not use the remote server's name as CVS server but your own machine. You can point MacCVSClient to yourself by entering "127.0.0.1" in the CVS server field. The port will be the local port that you used in the SSH port tunneling setup as described above. MacCVSClient stores machine name, port, and connection method in the CVS files of checked out modules. |
Throughput Limiting in MacCVSClient |
Heck, what is a "throughput limit" anyway? Why a throughput limit? Imagine the following (not so unusual) setup: you are connected to the internet over a V.90 modem dialup and use SSH to protect your CVS connection. In this case, you will have set up port tunneling on your local SSH side and MacCVSClient will effectively connect to SSH on your Mac and only indirectly to the CVS server on the remote end of the SSH connection. This all described above. If MacCVSClient now opens a connection to the CVS server and starts to send data to it, the following happens: MacCVSClient sends data to the SSH client that is running on the CVS client side, i.e. your Mac. This will work very fast, as no real network slows down data transfer. The local SSH client in turn will try to send all the data to the remote SSH server (the other end of the encrypted SSH connection). Remember we said, your Mac is linked up the internet over V.90. So the local SSH client will take much longer to send all the data to remote SSH server than it took MacCVSClient to send the data to the local SSH client. The moment MacCVSClient has sent all its data to the what it understands is the "CVS server" (the local end of the SSH connection) it starts waiting for CVS server responses. Here, the timeout value explained in Login Profile comes into the picture: the SSH client might take longer to send the data than MacCVSClient is willing to wait. A simple solution would be to increase the timeout value. That's not very nice though, as "reasonable" time outs (e.g. CVS server down; modem dialup disconnected) will take soooo much longer to fire through. A better solution is to specify a throughput limit in the login profile. This way, you can slow down MacCVSClient and make it send its data at approximately the speed of your dialup connection. Now, the moment the CVS client finishes sending is the moment the CVS server actually has received the last data. |
Quirks |
If you are using F-Secure SSH, you have to make sure you disable the "Allow local connections only" option in the port tunneling settings. F-Secure SSH doesn't seem to accept connections from MacCVSClient otherwise, if you specify "127.0.0.1" as the generic address of your machine. |
Rev. 1.13 | Copyright © 2000 Jörg Bullmann |