I might not have fully appreciated the elegance of SSH until tonight, and the following illustrates how much the Internet is all just a bunch of pipes. It takes a bit of practice though to get used to thinking about “remote” and “local” when you’re logged into a remote machine, forwarding something “in reverse” back to yet another remote machine (which in this case is the original machine from which you connected to the remote machine, in the first place). Here’s an example, via a problem I ran into.

Problem: Working with a MySQL server inside a remote LAN, where the only access I have into the LAN is through Remote Desktop to a restricted account on a Windows Terminal Server. Typically it’s easy to work with a remote MySQL server because these are generally on a network which is also running an SSH server (e.g., most Web hosting services); in that case, I would SSH in with a port forward: map my local port 3307 to the remote port 3306 (remote meaning, the end of the pipe at the SSH server). Given that there’s no SSH allowed in, in the problem instance, how can I use the tools installed locally on my machine (Navicat, Administrator, Query Browser, ODBC connections, etc.) with the remote database?

Solution: Install an SSH server on my local machine (over which I have full control, of course), and run the simple no-install SSH client PuTTY inside the Remote Desktop session. Configure port forwarding in the remote PuTTY instance: map the remote port 3307 to the local port 3306 (remote meaning, now, the end of the pipe on my home computer). PuTTY calls this type of forward “remote”. Terminology-wise, it’s not really a “forward” as much as a “pull”, as in, once the connection is established, any data my computer tries to send through port 3307 gets grabbed by the remote SSH client (with my local SSH server’s cooperation) and pulled back to that machine. Works like a charm.

Using this technique I could get remote access to a computer at work, say, through a restrictive firewall. Let’s say I work at a huge company with lots of computers. Of course, my work computer would be inside a private network, with a private IP address — no way to contact it from the Internet at large. But that’s no problem! All I have to do is, while at work, establish an SSH connection using PuTTY to my home computer’s SSH server. In PuTTY, forward some remote port (let’s us 3388) to “{{{localhost:3389}}}” . Now I can go home, pull up Remote Desktop Connection, and connect to “{{{localhost:3388}}}” — I should now be inside my work computer.

The beauty of all this is that it seems to me it would be unblockable (unless a nanny-like website filter is in place, which filters //all// Internet traffic, and disallows encrypted (e.g., SSL or “https”) pages or just any content it doesn’t understand, or does more extensive traffic analysis). But in general if one can surf the Web while at work, then at least one can establish an outbound connection on port 80. If my home SSH server listens on 80, I can reach it from work, going outbound. Data going the other way, coming back in, generally is inbound Internet traffic, the response to my request — such as Web page data (HTML, CSS, etc.). In this case it’s reversed, though: from the point of view of my theoretical work computer, the outbound traffic is data that I’ve requested from home. The inbound traffic, instead of being Web pages and such, are my data requests. What’s thought of as the client becomes the server. Easy as cake, right? I wish I’d known how to do this ages ago.