I have recently written two articles in my TechRepublic IT Security column about browsing securely from unsecured networks via an SSH proxy. I figured I’d go into more detail about how it works behind the scenes. The specific articles in question are:

Technically, you can use PuTTY as a secure proxy on other OSes (such as FreeBSD and Debian GNU/Linux) as well, but OpenSSH is not only the obvious and default choice on such platforms — it’s also probably a better choice than PuTTY when you have it available. Regardless of what platform and tool you’re using, the explanation is essentially the same — and I’ll refer to your “SSH tool”, regardless of whether it’s OpenSSH or PuTTY.

Here’s how it works, in brief:

When you set up the local proxy with the SSH tool, and you authenticate your SSH connection to the remote Unix/Linux system, you are creating two things: A. a connection to a remote system via SSH through which any data can be sent, including other networking protocols B. a local service that listens on a specific port and accepts whatever you give to it When you configure your browser to use a proxy, you are telling it to: A. send all HTTP requests to the SSH tool’s service B. listen for responses to those requests from the SSH tool’s service When the SSH tool receives requests from the browser, it forwards them to your remote Unix or Linux system. That forwarding is done over an encrypted SSH “tunnel”, which the local network only recognizes as a single SSH connection, regardless of what data may be passing through that connection. When the remote Unix or Linux system receives those requests, it acts as part of the proxy system, forwarding the requests to the Internet. When the remote system receives responses to those requests, it sends them back to your SSH tool. When your SSH tool gets them, your browser gets them.

As long as you have a broadband Internet connection at the location of the remote Unix/Linux system, you should not notice any real connection performance drop — unless the network you’re using with the local client system has an Internet connection significantly greater than that of the network where your remote system is connected. Assuming a 1.5Mbps connection at your home network (and assuming the home network is where the remote system is located), your connection to the Internet should be at a 1.5Mbps rate unless the network where you have your local client connected is slower.

Now . . . there may be some latency. You might be getting that 1.5Mbps rate (or whatever your ISP actually gives you, which may be less than the advertised 1.5Mbps) a tiny fraction of a second later than usual. It should be such a minor latency difference that you’ll never notice, however — unless there’s something odd going on, like your connection getting routed from your location in Kansas, through China, and back to Colorado where your home network is located. Of course, that’s absurdly unlikely. Like I said: “unless there’s something odd going on.”

There are a few more points that need to be made:

This is not the same as X forwarding over SSH, MS Windows Remote Desktop, or any other remote application access along those lines. All applications are being run locally, on your local client system. All that is being sent back and forth between your local client and your remote server is networking protocol data. If actual GUI application interface data were being sent back and forth: A. It could have a significant effect on networking performance. HTTP requests and responses alone are generally quite light-weight, carrying very little data across the network. GUI interface data, on the other hand, is very “heavy”, requiring a lot more data to be carried across the network connection — thus consuming more bandwidth that might otherwise be used to ensure quick response to network requests. B. Any file operations and other application behavior that depends upon local conditions treats the remote system as the local system, because it is the local system to the application. This means that (for instance) if you download a file with a browser run on the remote system via some kind of “remote desktop” software (like VNC, X forwarding, and MS Windows Remote Desktop), it will be downloaded to your remote server, on your home network — and not on the machine you’re using as your client system on the network away from home.

Because all the local, unsecured network sees is your encrypted SSH tunnel, nobody can “listen in” on your Web traffic through that tunnel. Any network packets sent through that tunnel are protected against eavesdropping of any kind by the strong encryption employed by SSH. The SSH protocol itself is designed so that your authentication (where login username and password) are sent to the server is encrypted as well, so that eavesdroppers cannot even pick that out of the network communications being sent back and forth. It is, however, still advisable to use key-based authentication, and to disable password authentication entirely on the server if you can, just to eliminate opportunity for brute force password cracking attacks and similar issues.

When setting up your proxy configuration options on your browser, don’t forget that you should configure it to use the localhost IP address (127.0.0.1) and the port number specified in your SSH tool’s proxy setup (8080 in the examples in both articles, though you may end up selecting a different port number). If you configure it to use the IP address or hostname of the remote network, your proxy connection won’t be set up properly.

Hopefully that helps settle any confusion or misunderstanding that may exist in readers of those articles. Let me know if you (my readers) have any questions.