SSH-over-HTTPS for fame & profit

In the past, I’ve discussed using SSH to circumvent restricted networks with censoring transparent proxies, but that relied on the restricted network allowing free SSH access on port 22 (what we call in the industry – the single network requirement for getting work done).

Unfortunately, there are restricted networks that don’t even allow that – all you get is the transparent censoring HTTP proxy (which has recently became the case with the free Wi-Fi on the Israeil Railways trains).

But fortunately for us, there is still one protocol which they can’t block, they can’t proxy and they can’t man-in-the-middle  – or else they’d break the internet even for people who only read news, search google and watch YouTube – that is HTTPS.

In this article I’ll cover running SSH-over-HTTPS using ProxyTunnel and Apache. The main consideration is that the target web server is also running some other websites that we can’t interrupt. The main content is based on this article by Mark S. Kolich, but since it only covers using plain HTTP and in addition to some simple changes in the example configurations I also wanted to cover getting an SSL certificate, here’s my version of the tutorial:

(more…)

Posted in Articles, Script Day, Tech | 1 Comment »

Setting up Subversion svnserve daemon on CentOS

When you want to host a Subversion repository on your CentOS (or RHEL) server, its quite annoying that the only options available to serve your repository are SSH (using the svn+ssh:// schema in the Subversion URLs – it is basically set up out of the box, not tweaking necessary) and Apache’s mod_dav_svn (using the http:// or https:// schema in the Subversion URLs – this is somewhat complex to setup but good instructions are easy to find on the web).

The main advantage of either of these methods is security: both have easy transport security (SSH by default, Apache if you set it to server over SSL) and are easy to setup authentication for (SSH authenticate against the system’s accounts using PAM and Apache authenticate against basically anything with a simple setup).

The main disadvantage of these methods are that they are slow (SSH is apparently somewhat faster then HTTP) and when supporting multiple large projects of many developers I started running into all kinds of weird connection errors when you try to manipulate many files on many projects at the same time.

Subversion itself offers another alternative using their own network service called svnserve – this is a standard unix daemon that listens on a specific port1 and uses a native protocol to communicate with Subversion clients (using the svn:// schema in Subversion URLs). It offers very good performance, but no transport security (encryption) by default. Another major problem with using svnserve as a network service is that while CentOS ships the binary itself (it is required as part of the way that the svn+ssh:// protocol is implemented) it doesn’t ship any support files to run it as a standalone service nor to help with its configuration. Also by default svnserve can only authenticate users using its own Apache-style password database file – which makes it unsuitable to integrate in large organizations.

(more…)

  1. port 3690 by default [↩]

Posted in Articles, Software | 5 Comments »