This week, we take a look at a part of what SSHKeychain makes really easy: secure tunneling.
Last week, we took a quick look at SSHKeychain, a tool that makes using OpenSSH (or just “SSH“) much simpler for Mac user who prefer to stay in OS X’s Aqua GUI instead of operating on the command line. This week, we’ll take a look at one part of what SSHKeychain makes really easy: secure tunneling.
An ssh tunnel, to put it simply, connects an outgoing port on a client machine with an incoming port on a server machine using ssh encryption and authentication. In so doing, any traffic you’d ordinarily send unencrypted is wrapped up in a protective layer of encryption before it ever leaves your machine.
Here’s a practical comparison we’re going to use a bit later:
What’s That Term?
Not sure what a particular term means? Check out the searchable PracticallyNetworked Glossary.
POP3 is a common protocol for receiving e-mail, and SMTP is how you send e-mail. While authentication with those protocols may be encrypted, the traffic passing over them is often not. You can tell if your POP3 or SMTP connections are encrypted most often by which ports you’re told to configure your e-mail client for. If you specify port 110 for POP3 or 25 for SMTP, the chances are good your traffic to those servers is unencrypted. Ports 995 and 465 are the most commonly used ports for encrypted POP3 and SMTP respectively.
So in a common scenario with unencrypted POP3, when you go to download mail, your computer opens a network connection with port 110 on the mail server. All your mail goes over the local network and the broader Internet unencrypted. That means if you’re reading POP mail from a laptop on an unsecured wireless network, anyone with a packet sniffer can read the contents of your mail.
That’s where ssh tunnels can help you out. To use one, you need an ssh login on the same machine where you download your e-mail.
A typical tunnel is constructed of a local connection to a port higher than 1024 (because ports below 1025 are considered “privileged,” which means normal users can’t have access to them) that then forwards all traffic to a destination port on another machine. To use the tunnel, you instruct your client software (an e-mail program in this case) to use the local tunnel port to communicate. All the traffic your e-mail program sends out is then passed securely over the tunnel and is then redirected to the correct target port on the server.
So if we want to build a secure POP tunnel to a mail server called “mail.foo.com,” we might use the local port 9110 to connect to port 110 on the POP server. Then we’d configure our mail client so that instead of connection to port 110 of mail.foo.com, it would connect to port 9110 of “localhost,” which is what computers call themselves for purposes of networking. The IP address 127.0.0.1 also works for this purpose.
It’s more complex to talk about than it is to do, really.
Here’s how we’d do the same thing using SSHKeychain and Apple’s own Mail program:
Open the preference window for SSHKeychain and click the “Tunnels” icon. To add a new tunnel, click on the “+” icon in the lower right of the window. The program will add a “New Tunnel” entry to the list of tunnels. Click on it to get information on the tunnel.
The first thing you’ll want to do is name the tunnel, which you can do under the “General” tab. We’ll call ours “POP Tunnel.” You can select whether to launch it when you start up SSHKeychain, and whether to launch it after your Mac wakes up from sleep. It’s the very safest to require some sort of interaction before opening a tunnel.
The next tab, “SSH,” is where you provide your login credentials on the remote server. In our case, we’ll assume our POP3 server and user account are on “pop.foo.com.” So fill that in under “Hostname” along with your ssh login information under “Username.” Unless you’ve been told to log in with ssh using a port besides ssh’s default port 22, just leave the “Port” field alone.
Next, you set up your “Local Ports,” which refers to the local ports you want to forward to your mail server. Click on the “+” in the “Local Ports” tab. Then doubleclick each field to fill in the values:
- Local Port: 9110 (it can be any port over 1024, but if we use 9110, it’s easy to see at a glance that we’re probably forwarding POP with this tunnel)
- Remote Host: mail.foo.com
- Remote Port: 110
Once you’ve filled it out, click once on the tunnel name to get SSHKeychain to commit the changes. (It could use a “save” button, but what do we want for free?)
Next, we need to activate our new tunnel. Do that by clicking on the SSHKeychain taskbar icon, mousing over the “Tunnels” menu, and selecting “POP Tunnel.”
If you want to make sure it’s working, you can open a terminal and try a simple telnet connection through it with the command:
telnet localhost 9110
Instead of getting your own machine, you should get some sort of “Hello” greeting from your POP server on the other side of the tunnel.
Next, we need to configure our POP client. Open Mail’s preferences and click the “Accounts” icon then click on the “+” in the lower left corner of the window. You’ll get a dropdown sheet to fill out. Select:
- Account type: POP
- Account description: something you’ll remember
- Full name: your real, full name
- Email Address: the e-mail address you use with that server
Click the “Continue” button and prepare for a bit of chop.
- Incoming Mail Server: set this to “localhost”
- User name: use your login on the POP server
- Password: user your password on the POP server
Click continue. You’ll get a warning, because Mail assumes POP connections are taking place over port 110. On your machine, port 110 isn’t listening for connections. You’ll be able to tell Mail which port to use a bit later, so for now ignore the warning and click “Continue.”
The next window asks what kind of security you’re using. This is most likely “Password,” so leave it unchanged and click “Continue.” For your outgoing mail server, use the settings you were given for now. Later down the road, you’ll probably want to construct a tunnel for that, too. Once you’re done with all this clicking, you’ll get a summary sheet. Click “Continue” then “Done.”
At this point, you’ll be back in the Accounts window. You’ll need to click on your new account, then click on “Advanced.” At the bottom of that panel is a setting for the port you’ll use. Since our tunnel is connecting locally at port 9110, fill that value out then close the preferences window to save your changes.
If all went well, clicking the “Get Mail” button will download your mail from the server. Depending on how you set it up in SSHKeychain, your tunnel will stay in operation even if you shut mail down.
If you want to secure mail sending as well, you can go back to the SSHKeychain tunnels preferences and build a new tunnel connection. Just use the settings:
- Local Port: 2525 (it can be any port over 1024, but if we use 2525, it’s easy to see at a glance that we’re probably forwarding SMTP with this tunnel)
- Remote Host: mail.foo.com
- Remote Port: 25
Save your changes, restart the tunnel. You can check if it’s working from the terminal again, this time with the command:
telnet localhost 25
You’ll probably get some sort of “Hello” or other response if it’s working.
Go back to Mail’s account preferences and under “Account Information” click on “Server Settings …” at the bottom of the window.
- For “Outgoing Mail Server” you should fill in “localhost”
- For Server port, you should fill in 2525
If your SMTP server requires a password, fill those in. Otherwise, select “None” for “Authentication” and click OK.
Now when you send mail, it too will be ssh-encrypted.
Though mail encryption is a very practical example, ssh tunnels can be used for a lot of other things. Almost any network service you’d use on your own server can be connected to securely from afar over an ssh tunnel: ad-blocking proxies and network file shares are popular choices, the former especially, because your Web traffic is kept more confidential than it would be if you were using a standard Internet connection, and because, frankly, tunneling out through ssh can get you around annoying and restrictive on-site filters since ssh traffic is often allowed through firewalls untouched.
So that’s what we’ve got for this week. Next week we’ll round out our look at Macs and ssh by considering how we can use OS X’s Folder Actions to build a secure network drop box.