Secure forwarding of services with SSH
In addition to remote login and file transfer, you can use ssh
to forward other services. Many services can be forwarded through
the same ssh "tunnel". ssh has built-in support for intelligent
X11 forwarding, and it can also do general forwarding
from a port on the local machine to an arbitrary IP and port on the other
end.
Another method altogether of doing this is to establish an
encrypted IP link with the remote host and use normal network
services over that link. This is often called a Virtual
Private Network (VPN). One can set this up by using
the PPP protocol over an SSH connection.
SSH will, by default, automatically set up X11 forwarding for you if you
run the ssh client with your $DISPLAY environment variable set (i.e. if you
are using X11). You can turn off this behaviour with command line
switches as well as with the config file in your $HOME/.ssh directory.
For most users, this is enough; it works quite transparently.
SSH does several things to facilitate "more secure" X11 forwarding.
I try to use the terms "ssh client", "ssh server", "X client", and
"X server" in this section to help clarify things. Remember that
the X server is the program that runs on your display and puts things
into your framebuffer; the X clients are the programs (like xterm,
fvwm, netscape) that connect to your display to tell it what to draw
where. When you are using ssh and X11 you are usually running the
ssh client on the same machine that the X server is running on (the
machine you are sitting in front of), and the ssh server is running
on the remote system, and you are running some X clients on the
remote system and the ssh server is forwarding them to the ssh client
which is forwarding them to the X server. Whew.
- Forwarding traffic.
SSH will allocate a "fake" display on the remote system and
attach a "dummy" X server to it. It forwards traffic sent
to the fake display through the encrypted tunnel. On the
other end, it then gets sent to whatever display your $DISPLAY
variable pointed to on the ssh client system.
SSH will automatically set your DISPLAY variable on the remote
system to the "fake" server.
- xauth magic cookie management.
Regardless of what sort of X11 authentication you are using on
the ssh client side, sshd will set up xauth authentication on
the remote end (you may be able to configure different behavior
at compile- or run-time, for Kerberos auth or something like that).
By default, the ssh daemon will run xauth for you on the remote end
to add a magic cookie to your Xauthority file. This magic cookie
is not the same as the one you are using locally, it's specific to
sshd's "fake" X server.
- logging.
sshd can log (and does by default) all connections it forwards. This
is nice if you are paranoid about other people on the remote end using
your tunnel to get to your display. You can make it log these to stdout
as well if you want, although that's annoying if you are using the same
ssh channel for a normal remote login session.
- Hanging around.
If you started a remote login session, then started some X clients through
the automatically created tunnel, then log out of the remote login session
before exiting the X clients, ssh will say something like this:
ssh has some special ~ escapes that you can use to tell it to go into the
background and keep forwarding the X11 connection as long as it's there.
You can press ~? to get a list...
So you can just press <CR>~& and it will get out of your way.
You can make it do this automatically and not bother with the remote login
session if you like:
You can forward arbitrary connections through your ssh tunnel using
the -L option. This makes your ssh client listen on a given port and
forward traffic received there through the tunnel; it instructs the
remote sshd to send the traffic to a given IP address and port.
1011 (sergent@hill-b-118:~) ssh -L 4242:shay:23 shay
1001 (sergent@shay:~)
*switch window*
1007 (sergent@hill-b-118:~) telnet localhost 4242
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
UNIX(r) System V Release 4.0 (shay.ecn.purdue.edu)
login:
ssh prints a message (in this case,
"fwd connect from sergent@127.0.0.1 to local port sshdfwd-4242")
to the tty running ssh so that you know the forwarded connection has been
made.
You can use "ssh -R" to forward a port on the remote machine to the
local ssh client.
This works fine for protocols like telnet and HTTP, but other
protocols aren't so simple. For example, FTP makes a connection
back to the client at an arbitrary port for the data connection.
Your ftp client and daemon don't know to negotiate the connection
through an ssh forwarded port. A good solution is to use HTTP instead
to transfer the file. Other protocols may have similar problems, and
similar solutions, too...
I hope to expand on this after the presentation.
The idea behind a VPN is to create an encrypted tunnel between two
sites on the Internet and route IP through the tunnel. To clients
and servers on either end it looks like a normal network; the encryption
and the fact that the rest of the Internet is between the two sides is
invisible. We can use ssh to implement something like this.
It's possible to run PPP (Point-to-Point Protocol) over an ssh connection.
PPP can handle several different sorts of network protocols and the like.
It represents the data as a stream of bytes, which ssh is great at
handling.
Check out the ssh-ppp Perl script,
which sets things up for you.
Jonathan Sergent
<sergent@purdue.edu>