[tlug] SSH Tunneling basics

["Stephen J. Turnbull" <stephen@example.com>]

Charles Muller writes:

 > Almost every time I go on an overseas conference trip, although I am 
 > able to access the web and my email accounts from my hotel room, I 
 > am usually not able to access my web site server via SSH.

What do you do to access the web site server?  Please be precise.  I
ask because recently I've always had SSH service at the hotels I've
stayed at in the U.S. and France.  Have you asked your local admin
whether their firewall passes SSH, or if SSH is restricted from (some)
other countries?  If the answer is "it should work", then the problem
is probably filtering on the hotel side.  If the answer is "filtered",
then setting up a tunnel is prohibited.  Do you really want to do it
in that case?  At my university, it's theoretically a firing offense.

OK, here's the basic concept.

Your computer sends a packet of information "into the cloud" where it
is passed from gateway to gateway until it reaches the destination.
The destination sends packets to you in the same way.  Source (ie,
return address) and destination are identified by 32-bit numbers (for
current standard IPv4, or 128 bits for TNG IPv6).  You don't need to
know more about IP, just that each host on the internet is identified
uniquely by such numbers, and that the DNS maps domain names to those
numbers for your convenience.  (You probably know more than that
already, though.)

If this sounds chancy and unreliable, you're right.  All modern
services use a system called TCP (transmission control protocol) in
which each packet is augmented with a checksum (for integrity
checking) and a serial number to allow concatenation of many packets'
content into a single reliably receivable stream.

However, note that this stream is going into the cloud and coming back
out at the other end; conceptually there's only one physical
connection between your local host and the remote host.  So each
packet is also assigned port numbers, which allows applications to
filter out packets containing information they don't need (and usually
can't understand).  This allows each application to see only the
packets that correspond to the stream of data it needs.

A server must bind to a particular port and listen there, because
otherwise how do you ensure the port number the local host sends to is
the one the server is listening to?  The client needs to know in
advance.  There are two ways this can happen.  One is the server admin
tells the client user what port to connect to.  This method is almost
arbitrary (subject to a requirement that the server have root
privilege to bind to ports numbered < 1024).  The other is that there
may be a public convention about what port a server uses (see
/etc/services for a long list).  FTP uses 20 & 21, SSH uses 22, telnet
uses 23, mail (SMTP) uses 25, HTTP uses 80, HTTPS uses 443, and so on.
You probably know most of this, too. :-)

Did you notice the word "filter" above?  Yup, there's the nub of your
problem.  Although filtering allows applications to "multiplex" over
the single "cloud channel", administrators also filter.  They may
filter out source or destination hosts (for example, to restrict
printers to hosts on the LAN, or to keep out Beavis and Butthead), but
they may also filter on ports.  In particular, it's common for hotel
ISPs to restrict outgoing traffic to connections to well-known web
services, and permit no incoming connections at all.  (Once an
outgoing connection is established, retunring packets are allowed
through.)  HTTP and HTTPS are absolutely necessary, FTP is probably
OK, mail (SMTP of course, but also several other services such as IMAP
and POP, as well as "secure" versions of the preceding services) all
have their own "well-known port numbers" (see /etc/services).

So you can probably connect to any of those services *and no others*
at the hotel.  This *may* be why you are unable to SSH to your host.

 > I have been told that what I need to do is set up Tunneling before I 
 > go away.

I think you need to find better advisors.  These folks are either
lacking a clue or two, or not listening to *your* problem.  If you
*need* tunneling, you are subverting your organization's firewall.
There is a straightforward way using only your roadwarrior and the
server, and there is a more reliable but circuitous way involving a
third host that you trust.  The first requires nothing special except
the option setting on sshd, and the second uses a tunnel (forwarding
through the encrypted connection).

The straightforward, cheap way is set up an sshd on a port that the
hotel firewall allows through.  This could be done via a server-local
tunnel (you can't do it from the client because you can't connect via
SSH in the first place!), but that seems kinda dumb to me.  Among
other things, you may want to configure the "last-resort" sshd with
more restrictions than the "daily-use" sshd on port 22.  The best port
to use is HTTP or HTTPS since you know those get through.
Unfortunately, your web server is probably using both.  After that,
I'd try an unused mail port such as POP, and after that I'd try FTP
ports.

For how to do it, I think you just add the "-p ##" option to the sshd
command line.  See the sshd man page, search for "port".

 > It seems that what I would be doing is setting up something on my 
 > remote server that will allow me access from my laptop when I am at 
 > my new location.

Yes.

 > If this it the case, then, do I need to make 
 > changes on both the remote server and on my local machine?

Yes.  The "ssh -p ##" option on the local machine must match the "sshd
-p ##" option on the remote server.

 > offers the below sample command:
 > 
 > ssh -N -p 22 will@example.com -L 2110/localhost/110

This is guaranteed to fail exactly when you need it.  22 is the
well-known SSH port which you know doesn't work in many cases.

 > With this as a template, how would I know that the values 
 > 2110/localhost/110 are right for my setup? Or how would I determine 
 > what the right values are?

You can't know for sure.  The circuitous and most reliable option is
to find an Internet-visible host that (1) can ssh to your web host and
(2) does *not* run a webserver on port 80.  This is your "gateway".
Then on the gateway run

ssh your.webserver.net -L 80/localhost/22

Note that the "localhost/22" part of the -L option refers to the
*server*'s point of view.  Ie, here localhost actually means
"your.webserver.net".

It might help if you draw a diagram using boxed hostnames for hosts,
numbered circles attached to the host for TCP ports, and lines between
circles to represent connections.  (The circles on your roadwarrior
don't need to be labeled; your OS will automatically pick one for each
connections.  You do need to use a different port for each connection,
though, to make an accurate picture.)  The particular suggestions for
notation here are pretty standard (eg, for concurrency theory diagrams).