Practical Security: Creating SSH Tunnels

Ensure secure communications, locally or over the Internet, without poking holes in a firewall and the complications of setting up a VPN.

WEBINAR: Live Event Date: September 20, 2017 @ 1:00 p.m. ET / 10:00 a.m. PT

Designing a Proactive Approach to Information Security with Cyber Threat Hunting REGISTER >

(Page 1 of 2)

In a previous article, I went over some of the basic functions of ssh. In that article, I mentioned that simple remote shell access was not the most interesting thing you can do with ssh. I pointed out that remote command execution was more interesting than mundane remote shell access. In this article, I'll discuss something that I think is even more interesting than remote shell access or remote execution: tunneling.

Reasons for Tunneling

There are two primary reasons to use ssh for tunneling. Before I give those reasons, I'll describe what tunneling is.

Tunneling with ssh is the process of wrapping some network communication with the encrypted ssh protocol. Tunneling involves an ssh client connecting to an ssh server, just as in "regular cases." But when the ssh client connects to the server, the client specifies the source and the destination for the tunnel.

The source is simply a bound network port that other processes can connect to. This port must either be managed by the ssh client or the ssh server.

The destination is another bound network port; but this time, it's some other network server that the other end of the ssh tunnel can communicate with. If this seems a bit unclear, don't worry; I'll get into more detail shortly with an example. For now, you can just think of ssh tunneling as secure port forwarding.

You may be able to derive from this description one or both reasons I'm about to give for using ssh tunneling. The first reason I'll give for using ssh tunneling is to connect two networks that do not have open access to one another. As an example, suppose you have an imap server setup on your home LAN. Also suppose that you have a laptop and want to be able to connect to your home imap server regardless of where you are. You could just open access on your home imap server to the world, but that's a scary proposition. You could setup a VPN on your router, but that's probably overkill. Or, you could create an ssh tunnel from your laptop to your home network when you want imap access. I'll give an example of this in the next few paragraphs.

The second reason for using ssh tunneling is that it encrypts the network communication. In the imap example, an added benefit of using ssh is that the email data is encrypted. Your private communications with friends, family, and potential employers are secure as they travel over the tunnel on the internet. But be aware that communication before it hits the tunnel and after it leaves the tunnel are not encrypted.

There are two types of secure port forwarding using ssh: local forwards and remote forwards. For local forwards, the ssh client manages the source port. For remote forwards, the ssh server manages the source port. Whether you select a local or remote forward will depend on which system is able to initiate the connection, which has an ssh server running on it, and where you need the source of the tunnel.

Here is an example of a local forward. Continuing the imap connection, suppose that I have a laptop named "dink" and I want to access an imap server on a machine named "ezr." Why not just connect directly to "ezr?" If "ezr" is behind a firewall and you can't connect to port 143, then using ssh tunneling is a great alternative. Here is an ssh command that will allow you access to imap on "ezr":

The "-L" in the command specifies that this is a local forward. The "8143" specifies that I want to bind as the source of the tunnel. The "localhost:143" specifies where to forward traffic on the remote end of the tunnel. While I specified "localhost" on the remote end, I could have specified any address and port that the remote machine could communicate with. Finally, "ezr" is the machine I want to ssh into.

Page 1 of 2

1 2
Next Page

Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.