Using ssh tunneling, every communication between the application running on your local client and the service running on the remote server is encrypted by ssh. So the most obvious candidates for tunneling are services that require the use of sensitive information such as a user name and password. Using ssh tunneling, you can safely enter your password, even if the application you use, transmits it in clear text. For more information about what tunneling really is and how it works, consult this page.
At O'Reilly's, there is an article describing the use of SSH tunneling in the context of wireless access to the Internet. Check it out too, it's from a different author, thus from a different perspective; it might give you more insight.
The key to successfully tunnel the service an application accesses, is the port number on which it is offered by the server. Below you will find a number of examples of services and how they can be tunneled such that you can use them in a secure way.
Using the table below, you can find which port a specific service uses and which servers in our department provide that service. If you want to use such a service from your local client, you must first establish an ssh connection with which to tunnel the service/port in question. Once the tunnel is established, you can use your usual application to access the service, but instead of using the server that is specified directly, you must now configure your application to use localhost.cs.kuleuven.be. The ssh connection will transfer everything from your local machine to the server on the other end of the tunnel.
A lot of services are offered on so called low or privileged ports (<1024). On most operating systems (but not Windows, nor MacOS and no, this is not good, allthough it might seem convenient ;-) you must have special privileges (i.e. being root or the equivalent) to be able to use these ports. If you cannot use these privileged ports on your local client and the service you try to contact uses one of these ports, you should check whether your application is able to use a different port for the service you want to use. In that way, you can tunnel the (port of the) service on the remote server to a port on your local client you can use and configure the application to use that port.
For example, to read your mail in a secure way using POP, you first execute the command
ssh -L 10110:pop1.cs.kuleuven.be:110 ssh.cs.kuleuven.beand once the connection is established, you can read mail using your regular POP-client by configuring it to contact port 10110 on localhost.cs.kuleuven.be to get your mail from. You can specify more than one -L option and thus build more than one tunnel in one ssh connection.
When using a GUI ssh-client, like SSH Secure Shell or Tera Term on Windows, you must set up an ssh connection to a server and configure that connection to forward the ports you want/need. Usually you can specify which ports to forward by means of a menu and corresponding dialog window. Consult the section about the different ssh clients on the Introduction page or the help pages with the specific client you use, for more information.
On Windows and MacOS, you do not need elevated privilegs to use privileged ports so you can use the same ports as the real server does, on your local machine. So the tunnels you must configure, look like :
then establish a connection to an ssh server machine of the department (e.g. ssh.cs.kuleuven.be) and then configure your usual client (in this example E-mail using POP) to look for the service in question on localhost.cs.kuleuven.be.
Local port: 110 Server: pop1.cs.kuleuven.be Remote port: 110
To establish the ssh connection, you must of course provide the correct pass-phrase or -word for your account. Moreover, in a tunneled password prompt, you will see that you get a prompt from the remote server, allthough you set up the connection to your local machine. This is exactly what it is supposed to do : allthough you connect to your local host, you really are communicating with a remote host through the ssh-tunnel.
When establishing tunnels, please make sure that your SSH tunnels are only accessible from your own machine: any configuration items such as Allow remote hosts to connect to tunnel should be configured such that only localhost can connect to any tunnel you set up ! If your tunnels are accessible for other machines as well, you create huge holes in the departmental security ... so please take care.
See the remote access page for a typical example of how to use/tunnel the below services.
|Reading mail with POP3||
The older POP2 protocol listens on port 109
The secure/encrypted POP3 protocol listens on port 995
Consult the E-Mail client pages for more information about reading your E-Mail using POP.
|Reading mail with IMAP2||
The (newer, but currently not used) IMAP3 protocol listens
on port 220
The secure/encrypted IMAP2 protocol listens on port 993
When tunneling IMAP using another port (on localhost), some IMAP clients might have problems finding the nested folders (i.e. folders in folders). If this is the case with your IMAP client, you should use this port on localhost as well. The reason for this problem is still unknown.
Thus, if your IMAP client has problems finding your nested folders, try tunneling IMAP via :
ssh -L 143:imap2.cs.kuleuven.be:143 ssh.cs.kuleuven.be
Consult the E-Mail client pages for more information about reading your E-Mail using IMAP.
|Sending mail with SMTP||25||mail.cs.kuleuven.be||
If you try to send mail via our mail servers, from another domain
than *.kuleuven.be, you can only send mail to addresses
within the kuleuven.be domain because our mail servers are
configured not to relay for arbitrary senders (for security and
By tunneling SMTP and thus sending via localhost.cs.kuleuven.be, you can send mail from arbitrary domains to any other domain, because you are authenticated (and tunneled) by the (trusted) ssh server.
Consult the E-Mail client pages for more information about sending your E-Mail using SMTP.
|Using the Netscape Directory Server with LDAP||389||directory.cs.kuleuven.be||Consult the directory pages for more information about using the directory server.|
|Using the Netscape Calendar Server||5730||calendar.cs.kuleuven.be||
The calendar client always uses this port to contact
the server, so you cannot use another one. This should be no
problem because the port that is used is a non-privileged
Consult the calendar pages for more information about using the calendar server.
|Accessing a Web Server||
any internal web werver
Web servers can easily be configured to use any port, but
port 80 is the default. Port 443 is the port for secure
access using https.
Web servers can be configured to deny access unless you know the password to certain web pages. These passwords are sent in clear text (unless the web server uses https) and thus are candidates to be tunneled as well.
There is no need to tunnel to the external web server(s) since they are meant to be accessible globally.
|Windows SMB File Sharing||139||any internal SMB server||
The other NetBios ports (137 and 138) seem not to be used in
plain file sharing. They are used for other functionalities
of the Windows networking facilities. With this tunnel, you
can connect to a file share, but you cannot
browse to it since browsing is done using UDP.
NetBios always uses this port to contact the server, so you cannot use another one. This could be a problem because the port that is used is a privileged one. On most Windows platforms however, even regular users can bind to a privileged port.
If you want to use SMB tunneling to some machine, your own machine may not share its own disks. Because by sharing the disks, this port is already occupied by the system for its own (SMB File Sharing) purposes and you cannot use it anymore for tunneling.
Only login and commands are encrypted, the data is not.
You must use passive mode to establish the data connection because otherwise the ftp server will try to contact the (machine on the) remote end of the tunnel instead of the (local) machine you started the ssh tunnel and ftp session on.
Most ftp servers do not allow a data connection from a different client machine than the corresponding control/command connection. This is a limitation for security reasons to prevent hijacking and/or spoofing of ftp connections.
Other obvious services with which you must use a user name and
password are telnet and/or rlogin. It makes no
sense however to tunnel these services because ssh is in itself
a complete replacement of these services. Everything you can do
with telnet and rlogin, you can do (usually
better) with ssh as well.
As a matter of fact, establishing an ssh connection to tunnel a service, requires you to login to the server. The login session you thus get, can be used for other commands/purposes, besides the tunnel as well. You mustn't of course tunnel a service when using ssh ... using it just as a login session, as a replacement for telnet and rlogin, is perfectly possible and even recommended.
Some applications however, use several services on the remote server to accomplish a certain task; ftp being the most commonly used such service, uses not only the ftp-control (or command) service to establish the connection and provide the user name and password, but also the ftp-data service to transmit the actual data over. You can have the control/command service being encrypted, but not the data service. In this way, your user name and password are not sent in clear text, but the data you want to have transmitted is. Mind the caveat as described with the FTP service in the above table, however.