SSH V

Tunneling Basics

'Tunneling' in SSH works by 'port forwarding': you establish a connection between a (non-privileged) local port and the port which runs the service to be tunneled on the remote machine (have a look at '/etc/services' for a listing of standard ports). Then you connect to the local port. All requests aimed at the local port are forwarded to the remote port via SSH, and thus encrypted.
Tunneling only works if the remote host runs an SSH server, naturally. To check if a remote server runs an SSH server, 'telnet' to port 22 of the remote host:

telnet {full name of remote host} 22

You should receive a message stating the version of the remote SSH server running. If you get a message like

telnet: Unable to connect to remote host: Connection refused

then the remote host does not run an SSH server.

The port forwarding syntax follows this scheme:

ssh -f {username@remote host} -L {local port}:{full name of remote host}:{remote port} {some command}

You can forward multiple ports and you can configure frequently used forwardings in '/.ssh/config' using the '~LocalForward' option. You can also forward remote ports to local ports. To forward privileged ports, you need to be 'root'.

Tunneling POP

You can use the Post Office Protocol to get your mail from your mail service provider (e.g. your ISP, university or employer). Tunneling it through SSH should mainly prevent network sniffers from detecting your POP password. As a bonus, you can use SSH's compression mechanism to make mail transfers faster.

Say you have got an POP account at pop.foobar.com, your user name is 'bilbo' and your POP-password is 'topsecret'. The command to establish an SSH tunnel then would be

ssh -f -C bilbo@pop.foobar.com -L 1234:pop.foobar.com:110 sleep 5

(For testing purposes, you might want to increase the value for 'sleep' to 500). This should prompt you for your POP password

bilbo@pop.foobar.com's password:

Having provided your password, use 'telnet' to connect to the local forwarded port

telnet localhost 1234

You now should get a READY message from the remote mail server.

Of course this method would require you to type in all POP commands by hand, which might be a bit - inconvenient ;-). To automate this, use Fetchmail (Fetchmail Via SSL/SSH).

Note that the IMAP protocol uses different ports: IMAP v2 uses port 143 and IMAP v3 uses port 220.

Tunneling X

If you want to run X applications off an SSH server on your local machine, log into your remote account, create a file called '/.ssh/environment' and put in this line:

XAUTHORITY=/home/{remote user name}/.Xauthority

(If '.Xauthority' doesn't exist on your remote account, it will be created automatically by SSH upon login.)

Logout and start an SSH session like this:

ssh -f -X -l {remote user name} {remote machine} xterm

This will open a remote xterm on your local machine. You can do that with every other X application which you are allowed to run on the remote host, too.

Tunneling VNC

VNC allows you to display and control laptops remotely. Passwords are sent unencrypted, which is bad when you want connect to a VNC server via an insecure network like the Internet.

The VNC server runs on ports in the 590x range, with x being the number of the display the server runs on. So Windows and Mac Os and Linux VNC servers listen to port 5900, Linux servers then listen to 5901 (second server) or 5902 (third server) etc.

Start the VNC server on the remote machine (here a Linux server) and then establish an SSH tunnel

ssh -C -L 5900:{remote machine}:5901 {remote machine} tail -f /etc/motd

Now start the local viewer with

vncviewer localhost:2

which points the client at the local forwarded port 5901.

You will notice that VNC is much slower than usual. To speed up things considerably, start the vncviewer like this

vncviewer -encodings "copyrect hextile" localhost:2

SSH's port forwarding feature allows some advanced VNC configurations, read 'sshvnc.html' in '/usr/doc/vnc-{...}/' (part of the vnc-doc package) for details.

Tunneling Linuxconf

Linuxconf is a central system configuration tool included in ML. It also allows remote administration. The Linuxconf FAQ says about using Linuxconf via SSH:

>

>"You can run the GUI locally and Linuxconf remotely. The command line is

>

>

remadmin ––exec {link_command} linuxconf ––guiproto

>

>Ideally, you will want encryption between the two machines. The best solution is to use ssh. So you will do

>

>

remadmin ––exec ssh -l {account} linuxconf ––guiproto

>

>This is very efficient and will allow you to use the GUI to administer boxes running on very slow (or congested links). All this fully encrypted."

This approach however requires Linuxconf to be installed on the client machine. Other possibilities are running it via X11Forwarding or just using the text interface in an ordinary SSH session.
Another possibility would be forwarding a non-privileged local port to port 98 of the remote machine, this would allow the use of a web browser for remote administration - with the advantage that the local machine doesn't need to have Linuxconf installed.

Tunneling Webmin

Webmin is a new, browser-based system configuration tool included since ML 7.1. It runs on port 10000. So you have to forward a non-privileged local port to port 10000 of the remote machine, like this:

ssh -f -l {remote user name} {remote host} -L 1234:{remote host}:10000 tail -f /etc/motd

Now point your browser at

http://localhost:1234

Related Resources:

SSH FAQ
Getting started with SSH

man fetchmail

Revision / Modified: Sep. 27, 2001
Author: Tom Berger

Legal: This page is covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.