If you’re stuck behind a school or university firewall, you’ll often find that they’re unreasonably restrictive (as a user – as an administrator, well actually, most of the admins probably think it’s a bit over the top too, given it really doesn’t stop much untoward behaviour for the inconvenience caused).

As long as you want web traffic to sites that haven’t been blacklisted or have restricted keywords in the URL (sigh), you’ll be fine. But if, for example, you need SSH access to a *nix server offsite, you’re stuck using various web based SSH console solutions.

As always, there are a variety of ways around it: some more complex than others. But a good place to start is the fact that most corporate firewalls are not only unreasonably restrictive – they’re also lazy.

Port 443 is used for secure web traffic, and the firewall can’t really do much to inspect the back-and-forth through that port (you know, by design), so in many cases, they just let traffic through without even bothering to check that it’s actually HTTPS.

I mean, really. If someone is trying to get access through port 22, they can probably figure out how to achieve the same end through 443 (this post, case-in-point).

Enter the demultiplexers – software tools to simply listen on 443 and direct SSH traffic to sshd and HTTPS traffic to httpd (the two kinds of traffic are trivially and flawlessly distinguishable).

I found the more recommended one to be SSHTTPS, whose chief advantage being that traffic is logged from its original source – very important in managing security, particularly if your HTTPS server is liable to get hit often and from many and varied locations.

Mine, to be frank, isn’t – the particular server I’d chosen hosts some very obscure sites (hipster web hosting – you wouldn’t have heard of it) and only one of them even uses HTTPS (tsk tsk).

However, having meaningful IP data in logs is always worthwhile, so I set about installing and configuring SSHTTPS (props on the name bee tee dubs).

PSA: Linux is free if your time is worthless

I didn’t get very far: although grabbing the various dependencies and compiling the tool itself wasn’t terribly hard, I stalled at configuring IPtables.

Yes, I’m ashamed to say, I never got entirely comfortable with IPtables, despite convincing it to do some pretty horrifying things with NAT a few years back (and I’m still not entirely certain how that was working), I just wasn’t prepared to sink the time fiddling with it over a web-based SSH session.

So while I’m sure it’s an excellent tool – I rolled over and installed SSLH instead, which consisted of the following two steps:

1. sudo apt-get install sslh
2. sudo vim /etc/default/sslh

Editing the config required me to insert the IP of my server. That’s it.

It was so easy as to be a little embarrassing that I hadn’t done this much, much earlier.

For those who need it, you can also configure it with libwrap to perform some (somewhat primitive) white/blacklisting despite HTTPS and SSH:443 traffic all appearing to be local.

Working, five minute job. I’ll call that a win.

Addendum:

If you, like me, are lazy and use ISPConfig, updating ISPConfig itself will break Apache.
The fix is pretty straightforward – you just need to correct the Apache ports.conf file:

#Anywhere you see it listening on port 443, it needs to be set to listen only to 443 on localhost (127.0.0.1)

Listen 80

<IfModule ssl_module>
Listen 127.0.0.1:443
</IfModule>

<IfModule mod_gnutls.c>
Listen 127.0.0.1:443
</IfModule>

This is automatically set when sslh is installed, but the file appears to not be touched again, regardless of uninstalling/reinstalling sslh.