Getting Out/Getting In

David Beecher

It's 3 a.m. and you have been paged by one of your monitoring systems that another service is down. Your employer requires extreme security. There is no modem pool behind your fireline with which you can get inside, and no one can justify the cost of a VPN to your CEO. Also, because your fireline is managed by another corporate entity, there is no access through the "front door" to allow you to tunnel in to do maintenance. That means it's time to drive down to the office and hope your keycard still works. Here's an alternative.

This article will explain how to use an SSH tunnel and port forwarding. I will show you how you can use SSH to form a secure tunnel from your workstation inside a firewall-protected network to your external UNIX workstation at home or a remote office. You can then use port forwarding to travel backward through the tunnel from your external workstation either to the workstation on which you originated the tunnel, or to any other services or workstation on your firewall-protected network. The real key here is that the workstation(s) or service(s) that you can reach on your firewall-protected network are not normally visible or reachable from outside that firewall-protected network.

One Tool, One Mission

SSH (SecureShell) version 2 is a tool that can make this happen for you. No fancy firewall configurations, no complex scripts, and no noise from the powers that be. SSH allows you to connect to a remote server with an encrypted tunnel over a single port and pass TCP traffic. It's most often used as a replacement for telnet, and can be used to pass other TCP traffic. I chose SSH2, because it solves many of the security issues currently related to SSH1 and as with most security tools, the latest versions are the best. This article describes how to tunnel out from your corporate workstation to your home computer using SSH and keep the tunnel open so that you can use it from home.

I've found this technique useful, but it may not be appropriate for every network. Your corporate security policy may prohibit using SSH in this way, but, in that case, it is still a good idea to read this article, so you know what one of your ambitious admins might try. You can decide whether this solution is appropriate for your network.

Let's review the requirements of our example environment:

• Because you are a UNIX sys admin, you probably have access to sensitive information on your corporate network. You can't jeopardize the security necessary to protect that information.
• Your actions should not be visible to anybody on the public network.
• Your activity should not be hampered by low bandwidth.
• It should not cost you anything.

SSH2 solves these issues in the following ways:

• Encrypted transmission protects your public transmissions from prying eyes, so your activities and priceless corporate data are protected.
• No one sniffing any portion of the public network through which you might be operating can tell what's going on. You are just noise that they will ignore.
• Getting high-speed access to the Internet is often a problem if you don't live on one of the coasts. We UNIX folks love the command-line interface and Lynx anyway, right?
• You can download the source code to SSH, configure and compile it on your systems free from: http://www.ssh.org.

Assumptions

I've made some assumptions here that match my own setup (and that of most other UNIX admins I know). The assumptions are as follows:

• You must have a connection to the Internet from your home workstation. It doesn't matter how you are connected. It could be a dial-up PPP connection over a modem, an xDSL link, cable modem, or even broadcast microwave.
• Your home workstation must not be behind its own firewall, or at a minimum you must control the firewall it is behind (my situation).
• It does not matter whether your home computer is on a home LAN or by itself.
• For the purpose of this article, your home workstation must be running UNIX (or any operating system capable of running an SSHD server daemon and supporting multiple logins).
• You must have SSH2 client and server installed on both your office workstation and your home workstation. The SSHD server daemon must be running and listening for a connection (mine is on the default port 22) on your home workstation.

Figure 1 is an example of both networks, one at my home on the left, and the office network on the right, both joined through the public network known as the Internet. My side is connected via an ISP. The corporate network is connected through a firewall and over a dedicated link to the Internet. There are actually multiple layers of firewall involved but that is neither relevant nor helpful for this discussion.

Making It Happen

Typically UNIX administrators (and others) on an office network are allowed to make connections to outside services (WWW port 80, Sendmail port 25, SSH port 22, telnet port 23, ftp port 21, POP port 110, etc.) Note that making this connection to Sendmail port 25 is a no-no from a corporate standpoint, because it could open up your corporation for SPAM/UCE liability. Your users should only be allowed to connect to port 25 on your own corporate LAN/WAN.

1. Your home workstation must be connected to the Internet with a TCP-capable transport such as PPP with dial-up modems. This means that before you left for work this morning you needed to connect your workstation to the Internet and had it ping some external system (e.g., your ISP's nameserver) every 120 seconds to keep the link up and alive. (See the man page on ping, for Solaris:

  ping -I 120

  ping -i 120

2. Your home workstation must have SSH version 2 configured (defaults are fine) and installed. SSHD needs to be running and listening to port 22.

3. From your workstation at work, you must initiate the connection to your home machine.

   ssh -R 32000:localhost:23 -l jdoe ppp25.den.myisp.com

If your username on your workstation at work is the same as your workstation at home, you can eliminate the "-l jdoe" portion of the command.

I picked port 32000, because it was not listed as a well-known-service port (cat the file /etc/services). It is a "high port" (above 1024), so you don't have to be root to attach to it, and most importantly, nothing else on my home workstation was bound to it. Later, I will use ports 32001 and 32002.

4. As SSH connects to your "home machine" (replace the ppp25.den.myisp.com with the actual IP address or the DNS name you received when you connected your home workstation to the Internet), you will be asked for a password. This is the password on your home machine; enter it.

5. If you can't get connected, simplify the command to see whether you can SSH to your home machine:

  ssh -l jdoe ppp25.den.myisp.com

7. At this step, I'll assume you got connected and logged in. You are now talking to your home workstation over an encrypted channel (see Figure 2). Congratulations.

8. Now review the messages that were sent while you were getting connected. If you don't see any messages saying "Remote port forwarding failed", then things are probably okay. If you do, then the port you tried to remote forward (in my example 32000) is probably being used by somebody else. Exit from your workstation and try again with a port number such as 32500. You can use any high port that is not in use by an existing daemon or other service.

9. If you got logged in without any error messages then try connecting back to your workstation at work through the secure tunnel:

  telnet localhost 32000

11. That proves it works. You didn't actually have to do the telnet in Step 9, but I wanted to show that it was working. Exit out of the login you made in Step 9. You should now be at a command prompt on your home workstation.

12. Some firewalls will close an open connection after a specified period if the connection is believed to not be in use. To prevent this, you might make your home machine ping itself (ping -I localhost) every 60 seconds (the resultant output from the ping command will travel through your SSH tunnel to your workstation at work thereby "refreshing" the connection). You may not need to do this; mileage may vary.

13. From home, log in to your home UNIX workstation and telnet to port 32000:

    telnet localhost 32000

Exploring a Little Further

Next, I will show a little more advanced capability. These tips (and the man page), should help you utilize the full power of SSH.

In Step 3 above, I used the keyword "localhost" to denote the local machine, because it causes the traffic to travel over the loopback interface rather than the network interface to communicate with the local host. You must ensure that "localhost" is set up properly in /etc/hosts (see the man page).

Instead of "localhost" you could have specified the name of any other workstation or server on your local (corporate) network. Wow! That's powerful. That means you could set up port forwarding for SMPT, POP, HTTP, or any other service.

Also, note that the names of your office workstations or servers do not need to be visible in the public domain name space, because neither side depends on the DNS of the other except to make the original SSH connection. SSH must know originally where to connect, but all the port forwarding is relative to each host's own network and namespace.

Here is an example of a longer SSH command (the new pieces are in italics) to show how to forward several services over the tunnel at the same time. (I used \ to escape to a new line to continue typing, but this is all a single command with no \ necessary.):

ssh -R 32000:localhost:23 -L 32001:smtp.abigcorp.com:25 \
-l jdoe ppp25.den.myisp.com

You could have replaced any of the "localhost" keywords with names of other servers on your corporate network. The downside is that SSH does not let you define multiple -R commands (or at least mine would not). If you have better luck, please drop me an email. I might not be able to respond to every query but will do my best.

Conclusion

That's really all there is to it. There are other cool things you can do with SSH, which I hope to expand on in future articles. I highly recommend reading the man page. It is well done and is an excellent source of information.

I have successfully used SSH and the technique described here on a variety of UNIX including: Linux (Slackware all the way back to 1.2.13, Red Hat 5.2, 6.0, 6.1), Solaris 2.7 x86, Solaris 2.7, 2.6, 2.5.1 Sparc, FreeBSD 4.0, Stormix 2000, Debian Linux, Caldera OpenLinux and many more.

I would like to thank the authors of SSH. It's a great tool and takes no more bandwidth or system resources than telnet, so it's perfect for low-speed dial-up. The SSH Web site: http://www.ssh.org. Lots of valuable information and FAQs. I also thank two associates who helped verify the accuracy of this article: Jason Nguyen and Tracy Harvey.

The software provided at http://www.ssh.org by SSH Communications Security, Inc. is free for evaluation purposes. (Please review their license agreement before using.) You should license it if you are using it in a commercial setting. Alternative completely free versions are at http://www.freessh.org. The folks at SSH are generous in allowing people to fully evaluate their software before using it. I don' think you can securely manage a publicly visible Internet site today without some form of SSH in your arsenal.

David Beecher is a Sr. UNIX Systems Administrator with over 12 years of experience. He has a background in analog and digital electronics, robotic control systems, and many years of programming in assembly language on a variety of platforms. He currently works for a technical services company and is on assignment at a well-known Internet destination. His home will soon be in Castle Rock, Colorado. He can be reached via email: dbeecher@b5media.com.