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
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
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
- 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
- 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.
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
- Your home workstation must not be behind its own firewall,
or at a minimum you must control the firewall it is behind (my
- 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
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
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
You also needed to find out what IP address was assigned to you or
what the reverse DNS was for that IP address.
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
The command above means: using SSH, map a port (32000) on the REMOTE
server (ppp25.den.myisp.com) to my local machine (your UNIX
workstation at work) port (23) and login to the REMOTE server (ppp25...)
as user "jdoe".
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
6. If that doesn't work, check whether you can traceroute
or ping to your home machine. If not, your home machine may
have been disconnected. Test whether you can telnet to port
22 on your home workstation (telnet ppp25.den.myisp.com 22).
It should come up with an SSH notice after it connects. If not, check
whether you can connect to any port you know is active on your
workstation. If none of these work, something is amiss and you need
to scrutinize your home workstation's setup.
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
10. You should be presented with a login prompt from your workstation.
It's okay to use telnet here because it is being encrypted
over the SSH tunnel.
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
14. You should be presented with the login prompt of your workstation
at work. Once you log in, you are exploiting one of the best features
of SSH. You now have complete access to your work environment from
home, and communication between your home and office is encrypted.
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
Besides performing the original "reverse" (-R) port
forwarding of your company workstation's telnet port (23)
to your home workstation's port 32000, this command also forwards
(-L) connections on port 32001 on your corporate workstation
to the SMTP (25) default port of your company's mail server.
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.
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
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: email@example.com.