The Firewall Won't Hold Me Back!
I've been using a semipublic wireless Internet service from time to time. Unfortunately, access on that network is limited to the most basic services, like the web (nonsecure and secure) and DNS. IM, email, VPN, even iTunes' access to Gracenote is restricted.
But I've begun to work on a way to get around it all. The first step is ssh. That's the spoon I've taken from the prison cafeteria that will help me tunnel (a pun, ha ha) under the wall.
When I saw my access was limited, my first thought was to use my employer's VPN service. However, it turns out that this public network doesn't allow traffic on the ports that VPN uses. I got a list of the ports from a tech support person at work. There's three (or four?) of them. Experimenting with them confirmed to me that I can't reach them from here.
My next thought was that if I could use ssh to tunnel the VPN ports from my computer on the public network to my other computer at the office, then I would be all set. But ssh isn't allowed here, either. So I set out to learn how to move the ssh service at the office to a port that is allowed.
First, my laptop and my computer at work both run Mac OS X of various versions. So I took a couple of hours to read about moving ssh from its usual port (22) to another one (like 2200, 2022, 1138, whatever). I found the right way to get the MOSX launchd to use a new port so it would alway be ready when the system reboots.
That worked well, so I needed to pick a port that the public network allowed connections to and was likely to be available on my office computer. My first thought was DNS, port 53, since my office computer was not going to be running a DNS service any time soon. But then I learned that DNS was usually UDP, not TCP. Since I didn't know if the public network would allow TCP connections to that port (they can limit that kind of thing), I thought about other port options.
I decided that HTTPS, port 443, would be a good choice. Like the ssh that I would use on that port, it is encrypted and HTTPS connections could be long-lived. So my ssh traffic on that port would not look unusual if anybody were to monitor the public network's usage. The only sacrifice is that I wouldn't be able to run a HTTPS service on my office computer. I wasn't already doing that, so it wasn't a big sacrifice. It worked great on my laptop's loopback interface, so I was all ready to set it up on my office computer next time I was there.
After I stopped for a lunch break, I thought that if I find a web-based ssh service that I think I could trust, I would only need to use it for a short time just to start up the ssh service on the new port. I Googled for web-based ssh clients and I found GotoSSH.com. I Googled further to look for reports of security problems with GotoSSH. I didn't find any, so I felt a little more relaxed about using it. The only problem was that GotoSSH isn't free. The web site says it, "costs only $". Yes, just a dollar sign and no number. But, I could sign up for a 2-minute trial. That was going to be tight, so I made sure I knew exactly what I wanted to do, so I could get it all done in two minutes.
Once I was sure I was ready, I used GotoSSH to connect to my office computer. I logged in and as quickly as I could, I edited the launchd ssh configuration to accept connections on the HTTPS port, then restarted the service. Then, I tried the ssh service from my computer, through the public network.
Eureka, it worked!
I immediately closed down my GotoSSH connection, then on my new direct ssh connection, I disabled the normal ssh port. I did that just in case the GotoSSH people couldn't be trusted after all. I also changed my password on my work computer and generated a new ssh key.
So, that is my first step in getting more out of this public network. Now that I have a computer on the outside of the firewall that I can access a shell on, I can use that shell to set up ssh tunnels for other services. I believe I will concentrate on the VPN next. If I can just get the VPN working, that should handle the rest of the connections from my laptop on the public network.
I don't expect blazing speed from this network connection when I'm done. I'm using a wireless network with spotty coverage. The rest of the network here is shared with other demanding users and throughput may be throttled. My remote computer at work will act as another piece of networking equipment which could make connections slower, but since only I use it, it shouldn't be bogged down much. Finally, funneling all my connections through the VPN client and remote VPN server will further reduce bandwidth. Fortunately, I don't plan to do a lot of heavy work with this setup. Mostly web work, very little interactive remote shell work.
As an indication of the stability of my new ssh service, I have had a ssh connection open the whole time I've been typing this blog entry. That's been at least thirty minutes. This is a good sign.