CVS from behind firewall

The ports

CVS member access can be done on cvs.sv.gnu.org:22 and download.sv.gnu.org:443 (without long-term warranty for the latter).

Anonymous CVS can be done on cvs.sv.gnu.org:2401. As long as you have 'CONNECT' privileges on the proxy, it should work, even if the connection is not TLS (eg. cvs pserver is not crypted).

Ethical issues

First, this documentation is complainware. It means that you can freely use it provided you complain to your local system administrator, or to your Internet Service Provider (ISP), if you are using a restrictive Internet environment as described below.

This FAQ is about a system we had to setup so that people behind restrictive firewalls, or proxies, or ISP that blocks some ports, can access our CVS services. More precisely, those people experience outgoing traffic filtering. Please read the following attentively.

There is no security issue in allowing people to access a remote CVS repository, or more generaly a remote SSH server. It is rather a matter of policy, when administrators decide what kind of action they allow their users to perform. For example, some ISPs decided to block outgoing traffic to port 25 (smtp) so as to keep people from sending mail using any other service than their SMTP smarthost, and think they can fight spam (and control their users) that way.

You should know, however, that it is possible to bypass such a setup by two ways:

First, systems like https://tor.eff.org/ can be used, at the price of a decreased connection speed, to redirect your traffic to any public computer, and any port, provided you have outgoing access to port 80 (http) and 443 (https) - which anybody should have whatever their setup. Unlike what we stated in a previous version of this document, Tor now does work from behind either a firewall or a proxy.

Therefore, limiting outgoing traffic with per-protocol rules cannot be effectively done. Moreover, a lot of websites now use HTTPS, a secure, encrypted protocol that encapsulates HTTP. That means it is not possible for the firewall to tell anything more than the fact it is SSL-encrypted traffic, and cannot try to analyse the packers to discover what the user is actually doing. Preventing HTTPS traffic is not an option, unless the system administrator wants to prevent access to all e-commerce websites, as well as websites that only use HTTPS.
The other way to bypass a restrictive setup requires a bit of work from the remote host administrators. Basically he opens the same service but on port 443 (https). This removes the proxy and speed limitation from the above. This is used, for example, by https://docs.ovh.com/gb/en/ so that people can send mail even if their ISP block port 25 (smtp). We also setup CVS over SSH on port 443 (https) in addition to port 22 (ssh) to allow people to access our CVS repositories.

Note: we implemented that method, without warranty, for project member SSH access only - not anonymous access. Anonymous access is available via pserver which ought to be available to you, just like HTTP.

In conclusion, remote outgoing traffic is a burden for us (the Savannah hackers) and does not bring any real value.

That's what it is important that you tell your local system administrator or your ISP about it. You can for example refer them to this page. I mean it: that's the only clean and reliable solution to access Savannah and other services on the Internet. You need to mention it to your local sysadmin so he realizes that opening outgoing traffic is needed, and that trying to control is ineffective and just a burden to his/her users.

Now let's see how to access our CVS services using any of those methods.

Tor

(check http://wiki.noreply.org/noreply/TheOnionRouter/TorifyHOWTO#SSHtorify for more information). This method can be used to access any remote CVS repository. Here are instructions for a Debian GNU/Linux-based distribution:

# Install Tor. Check http://tor.eff.org/download.html for more information
aptitude install tor
# Configure Tor
cat <<'EOF' >> /etc/tor/torrc
# Old config syntax:
#FascistFirewall 1
#ReachableAddresses *:80,*:443
# New config syntax
FirewallPorts 80,443
##If you use a proxy:
#HttpProxy  yourproxyhost:port
#HttpsProxy yourproxyhost:port
EOF
# Restart Tor
invoke-rc.d tor restart

Now you should be able to use tor the easy way:

export CVS_RSH=ssh
torify cvs -d:ext:username@cvs.savannah.gnu.org/cvsroot/project co module

If you don't like typing 'torify', you may want to have a look at http://shellscripts.org/project/toraliases

If for some reason that doesn't work (notify us!), you can try the difficult way:

# Get connect
wget http://www.taiyo.co.jp/~gotoh/ssh/connect.c
# Local copy here: https://savannah.gnu.org/maintenance/connect.c
# Compile it
gcc connect.c -o connect
# Install it somewhere in your path
install -m 755 connect ~/bin/
# Configure SSH
cat <<'EOF' >> ~/.ssh/config
Host cvs.savannah.gnu.org
  ProxyCommand connect -S localhost:9050 %h %p
EOF

# You now can use SSH normally
export CVS_RSH=ssh
cvs -d:ext:USERNAME@cvs.savannah.gnu.org/cvsroot/PROJECT co MODULE
...

If you are not root on your machine, you will need to compile Tor by hand, but that should not be a problem.

We heard that some ISPs block most of the Tor nodes. If that's the case, the fist move is to explain your system administrator that this is blocking your legitimate work, and ask him/her the reason of this filtering (we would be pleased to know that reason as well). Last time a Savannah user had this kind of issue, he didn't contact the sysadmin and didn't even know why Tor nodes were blocked - we don't think that's the way to go.

Using download.sv.gnu.org:443

Please note again that this is a burden for us to offer this method and is not garanteed in the long run, nor will we necessarily apply it consistently to other services. Here are generic instructions for the GNU/Linux OS:

If you are connecting through a proxy, you first need to do this:

# Get connect
wget http://www.taiyo.co.jp/~gotoh/ssh/connect.c
# Compile it
gcc connect.c -o connect
# Install it somewhere in your path
install -m 755 connect ~/bin/
# Configure SSH
cat <<'EOF' >> ~/.ssh/config

Host download.sv.gnu.org
  ProxyCommand connect -H PROXYHOST:PROXYPORT %h %p
EOF

Replace proxyhost by your proxy host name, and proxyport by your proxy port (3128 if you use Squid).

Now, proxy or not, you need to tell SSH to use a different port:

# Create a wrapper, in your path
cat <<'EOF' > ~/bin/sshwrapper
#!/bin/sh
exec ssh -p 443 $*
EOF
# Give it executable permissions
chmod 755 ~/bin/sshwrapper

# You now can use SSH with sshwrapper
export CVS_RSH=~/bin/sshwrapper
cvs -d:ext:username@download.sv.gnu.org/cvsroot/project co module
...

Troubleshooting

If that doesn't work, try typing:

Tor:

$ ~/bin/connect -S localhost:9050 download.savannah.gnu.org 443
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
<Ctrl+d to exit>
$ socat - -SOCKS4A:localhost:cvs.savannah.gnu.org:443,socksport=9050
...

HTTPs Proxy:

$ ~/bin/connect -H yourproxyhost:yourproxyport download.savannah.gnu.org 443
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
<Ctrl+d to exit>
$ socat - -PROXY:yourproxyhost:download.savannah.gnu.org:443,proxyport=yourproxyport
...

If you don't see the the remote SSH version after a few seconds, then there's a problem; please note any error message and contact us if you can't fix your configuration.

If that is not enough

It is pretty easy to make any redirection by your own means. Buy a minimal virtual server for you and you collegues (as cheap as 9 USD per month), so you control an external IP, and use the 'redir' (or 'stunnel') tool to redirect port 443 to any plain or crypted port you want. To redirect traffic from you.somehosting.net (port 443) to cvs.savannah.gnu.org (22):

 root@you.somehosting.net:~$ daemon --respawn -- redir --syslog --lport 443 --caddr=cvs.savannah.gnu.org --cport=22

For cvs-pserver::

 root@you.somehosting.net:~$ daemon --respawn -- redir --syslog --lport 443 --caddr=cvs.savannah.gnu.org --cport=2401

You then can hit on you.somehosting.net port 443 to access the target Savannah service you need.

Ultimate block

All those methods are based on a single feature: when https access is allowed, there's no way to analyse the (encrypted) traffic. In particular, URL-based filtering doesn't work with https. So you can do whatever you want on remote port 443.

However, I've already seen networks where https was simply disallowed, probably for that reason. Only port 80 was available and thus the only choice available to you was: talk the network administrator into allowing outgoing CVS access.

So don't believe those tricks can work in the long term. Some admins are already blocking Tor nodes, disabling port 443 is just the next step. The only real work around is talking with your system administrator.

ToDo

Reformulate, taking 3 attitudes into account (explain to sysadmin/boss, workaround, complain to Savannah Hackers)
Provide solutions to use port 2401 and 22; then provide alternatives to use port 443 (no need for Tor if you use port 443 directly)
Provide solutions progressively: laxist Proxy (allow CONNECT on 22+2401), fascist proxy (only 80+443), firewall, proxy without CONNECT (you're doomed)...
Provide progressive answers for local sysadmins/gurus / suspecting bosses (drop the firewall/proxy; keep the proxy but allow CONNECT to ports 22+2401... (this is for work, not fun!))
Explain where to get socat (aptitude install socat)
Unify the 'get connect here:' statements
Discussion related to the fact we closed anoncvs over ssh at https://savannah.gnu.org/forum/forum.php?forum_id=4168