From owner-freebsd-hackers Thu Dec 12 08:58:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA22740 for hackers-outgoing; Thu, 12 Dec 1996 08:58:59 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA22735; Thu, 12 Dec 1996 08:58:55 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id IAA17824 ; Thu, 12 Dec 1996 08:58:44 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id IAA17705; Thu, 12 Dec 1996 08:57:16 -0800 (PST) Message-Id: <199612121657.IAA17705@austin.polstra.com> To: roberto@eurocontrol.fr Subject: Re: Fwd: CVSup with SSH Newsgroups: polstra.freebsd.hackers In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org, marcs@znep.com, jkh@freebsd.org Date: Thu, 12 Dec 1996 08:57:16 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk About running CVSup through a firewall by using SSH port forwarding, I wrote: > I've been thinking this over. I don't think it can be made to work > with the current release of CVSup. Good news, I was wrong! It seems to be possible after all. Here is the recipe: * Invoke ssh with: -L 5999:localhost:5999 -R 6666:localhost:6666 ^^^^...........^^^^ (any free port) Note that it's "-L" in the first one and "-R" in the second one. * Specify "host=localhost" in your cvsupfile. * Invoke cvsup with "-P 6666". I tried a quick test of it between two machines here, and it seemed to work OK. I checked both sides of the link with netstat, and the connections were all set up right through the ssh channel. I did a small update which worked and completed successfully. It definitely needs more thorough testing, though. To work with CVSup, a proxy has to be very good about handling some strange communication patterns. For example, it is normal and common that at least one of the 4 unidirectional channels is completely full and blocked by flow control. Yet the other 3 unidirectional channels have to continue to flow unimpeded. If the proxy falls short in that regard, deadlock results. Please let me know how it works out in practice. Here's how the connections are set up under this method: * Client connects to port 5999 on its own host, and that gets forwarded to port 5999 of the server host. Because of the forwarding, both client and server think they're connected to "localhost". * Client sets up a second socket, binds it to "localhost:6666", and listens. * Over the first channel, client instructs server to do a connect to "localhost:6666". * Server does the connect. Because it's "localhost", it connects to its own host rather than the client's host. Sshd is already there, listening for the connection. It forwards the connect to port 6666 on the client host. The key to it working is that localhost has the same address everywhere, but it references different hosts depending on where you are. Thanks to Marc Slemko for the idea! John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth