We are often asked, “How can I tunnel my web browsing over SSH?” The usual reasons are for privacy or for browsing across a firewall. The SSH port forwarding we’ve described so far doesn’t meet this need very well, but there is another flavor called dynamic port forwarding which does. We’ll call the previous technique “static forwarding” in contrast.

Suppose you’re at home, using your home machine H, and need to access a web server W1 at work, but your employer’s internal network is behind a firewall. You might attempt to do this through a bastion server at work (say, B) which you can log into via SSH; and then from B, you can reach whatever internal web servers you want. So you create a tunnel using the following port-forwarding command on home machine H:

    $  ssh -L 8080:W1:80 B         This runs into problems

and point your web browser on H at http://localhost:8080/. This is a reasonable try, based on forwarding as we’ve seen it so far, but there are lots of problems:

Clearly, static port forwarding is woefully inadequate for this scenario. You could get around individual problems by editing your host file or stopping now and then to forward another port, but who wants the annoyance? And such a burdensome solution isn’t exactly convenient to explain to your Aunt Mae. Or your boss.

We can address problems 1 and 2 by making a realization: that we want to redirect the web browser over SSH without fussing with the URL. Most browsers have just such a feature: a proxy. We can set the browser’s HTTP proxy to our SSH-forwarded port localhost:8080; this means it always connects to our forwarded port in response to any HTTP URL we provide. The browser assumes this port leads to a proxy server that knows how to get the content for the various web servers we seek, so the browser doesn’t have to contact those servers directly.

Proxying gets us part of the way there, but doesn’t solve problem 3: what happens if we hit a link to a hostname besides W1? The browser sends it to W1 anyway via its proxy setting, but W1 won’t know how to handle it, so we’ll get a web server error along the lines of “unrecognized URL.” We can’t feasibly deal with this manually; not only would we have to forward another port, but also we’d have to reset the browser to proxy through the new port, at which point it could reach the new URLs but not the old ones on W1! That’s just a mess...what we really need is a way for the browser to communicate dynamically with SSH itself, telling it to forward to the correct web server for each URL the browser handles. And indeed, there is a feature to do exactly this, called dynamic forwarding or SOCKS forwarding.

SOCKS is a small protocol, defined in RFC-1928. A SOCKS client connects via TCP, and indicates via the protocol the remote socket it wants to reach; the SOCKS server makes the connection, then gets out of the way, transparently passing data back and forth. Thereafter, it is just as if the client had connected directly to the remote socket. The OpenSSH and Tectia syntax for this kind of forwarding would be:

    # OpenSSH
    $ ssh -D 1080 B

    # Tectia
    $ ssh -L socks/1080 B

We’ve switched to port 1080 since that’s the usual SOCKS port; 8080 or any other port would do, as usual. Note that there’s no destination socket in either command, just the local port to be forwarded; that’s because the destination is determined dynamically, and can be different for each connection. We can use this solution only if the browser has an option to use a SOCKS proxy (as most do).

This solves the whole problem neatly! The process goes like so:

Each time a new connection arrives on port 1080, it can be forwarded to a different socket. This might seem odd if you have static forwarding firmly in mind, but it’s just an extension of what you already know. With static forwarding, the SSH client still creates a new channel for each connection; it just sends them all to the same place. With dynamic forwarding, SOCKS allows each connection to indicate its own destination, and SSH obliges.

No special support is required for dynamic forwarding on the SSH server, since it in fact uses the same mechanism as static forwarding. Only the client needs to support dynamic forwarding.

So, this would be a perfect lightweight solution: complete remote web browsing with just SSH. Ah, if only we lived in such a simple world....

    # Tectia
    # In one window:
    $ ssh -L socks/1080 B
    # In another window:
    $ export SSH_SOCKS_SERVER=socks://localhost:1080/
    $ ssh -o'usesocks5 yes' HOST1