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:

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:

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:

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.

[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.