By Bri Hatch.
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 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:
where the bits are defined as follows:
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
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 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
~# 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. If you need to
allow other machines to use this tunnel
then you can supply the
Above I've described how to create these tunnels from the command
line. Luckily you can also define your tunnels inside your
Host revTelnetTunnel HostName mail.my_isp.net RemoteForward 2323:localhost:23 GatewayPorts no
Then any time I '
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.
 Yes, slight change in our timeline.
 "Completely" because the endpoint was the SSH client
 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.
 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 firstname.lastname@example.org.
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_Securityemail@example.com.