Summary: Want to encrypt an otherwise cleartext transmission? SSH Tunneling may be the tool for you.

Last week we discussed SSH's ability to create LocalForwards, and a quick application of them. This week I'll discuss the converse, RemoteForwards. Next week[1] I'll discuss a very important distinction about what part of Local and Remote forwarded connections are crypto encapsulated, and settle "Alice" and "Bob"s debate from last week.

As a reminder, an SSH local forward is a tunnel from your local machine through the SSH server. An SSH Remote Forward is just the opposite - a tunnel from the remote machine through the SSH client. The syntax is similar:

  -R remote_port:destination_host:destination_port

where the bits are defined as follows:

-R

Create a remote forward (bind a port on the remote machine [SSH server], and forward it back here through the SSH client machine.)

remote_port

The port on the remote machine [SSH server] that /usr/sbin/sshd will listen on. This can be a port number or a service name like http, pop3, or mysql.

destination_host

The destination host (name or IP address) from the perspective of the SSH client machine. This can be a host that is not accessible at all from the SSH server. For example if your SSH sessions ends outside a firewall and the SSH client can resolve "somebox.internal.our_company.com" that's fine, even if the SSH server can't reach or find an IP address for that machine directly.

destination_port

The port on the destination_host to which it should connect.

For example if you used the following

  workbox$ ssh mail.my_isp.net -R 2323:localhost:23 sleep 99999

then when you connected to port 2323 on homebox, it would be silently tunnelled to localhost's TELNET port (23). Remember - in this case localhost is being evaluated on the SSH client, so localhost is the SSH client 'workbox', not mail.my_isp.net. The sleep 99999 line just makes sure that the connection stays alive for a while. From another window you can run the following:

  mail.my_isp.net$ nc localhost 2323

  **********************************************
  Welcome to workbox.internal.our_company.com,
  here at BigCompany, Inc.  This machine can
  only be accessed from inside our firewall.
  That's why we allow Telnet, because everything
  is secure inside here, you know.
  **********************************************

  workbox login: 

You can see that connecting to the local port 2323 on the SSH server (mail.my_isp.net) resulted in a connection to the TELNET port (23) on the SSH client machine, 'workbox'. Since this connection was tunnelled inside the existing SSH session, it is completely[2] encrypted, with almost no work on your part, requiring no knowledge of cryptographic algorithms whatsoever.

As with LocalForward's, you can use ~# from the window that ran ssh to see active connections:

  ~#
  The following connections are open:
    #1 127.0.0.1 (t4 r2 i0/0 o0/0 fd 7/7)

You can open multiple connections at a time, and each is tunnelled securely through the encrypted SSH channel.

Recent versions of OpenSSH only allow the remote SSH server machine to connect to the tunnelled connection.[3] If you need to allow other machines to use this tunnel[4] then you can supply the -g option to ssh as well.

Above I've described how to create these tunnels from the command line. Luckily you can also define your tunnels inside your ~/.ssh/config file. For example if I want to create the above tunnel any time I connect to my external mail server by running 'ssh revTelnetTunnel' I can add the following in my config file:

  Host revTelnetTunnel
  HostName mail.my_isp.net
  RemoteForward 2323:localhost:23
  GatewayPorts no

Then any time I 'ssh revTelnetTunnel' it will automatically create this remote forward. (I included 'GatewayPorts no' above, but that is actually the default anyway.) If I want to connect without the port forwarding, I just ssh mail.my_isp.net like normal.

I find that RemoteTunnels are most frequently used when connecting from a more secure network (inside a corporate firewall) to a less secure network (your ISP, home machine, etc) to allow a tunnel back into the secure network. This may very well violate your company's security policy, and you could get into a lot of trouble.

NOTES:

[1] Yes, slight change in our timeline.

[2] "Completely" because the endpoint was the SSH client

[3] It does this by only binding the port for localhost 127.0.0.1 - no other machines should be able to reach this IP address.

[4] You better do this with great care if it is a protected resource you are accessing - you do not want to let some random cracker into a private network.

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's mighty glad that, long ago, he replaced Sendmail with Postfix, and BIND with DJBDNS. He's particularly glad that both have come out with vulnerabilities - the dry spell was making him worry that they might finally be secure, and he'd need to pick new software to use as the butt of his jokes. Whew - that was close. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the March 09, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.