Port Forwarding
Port forwarding, or tunneling, is a way to forward otherwise
insecure TCP traffic through SSH Secure Shell. You can secure
for example POP3, SMTP and HTTP connections that would
otherwise be insecure - see Figure Encrypted SSH2 tunnel.
![tunnel1-1.gif]()
Figure : Encrypted SSH2 tunnel
The client-server applications using the tunnel will carry out their own
authentication procedures, if any, the same way they would without the encrypted
tunnel.
The protocol/application might only be able to connect to a fixed port
number ( e.g. IMAP 143). Otherwise any available port can be chosen for port
forwarding.
Privileged ports (below 1024) can be forwarded only with root privileges.
There are two kinds of port forwarding: local and remote forwarding. They
are also called outgoing and incoming tunnels, respectively. Local port
forwarding forwards traffic coming to a local port to a specified remote
port.
For example, if you issue the command
ssh2 -L 1234:localhost:23 username@host
all traffic coming to port 1234 on the client will be forwarded to port 23 on
the server (host). Note that localhost will be resolved by the
sshdserver after the connection is established. In this case localhost
therefore refers to the server (host) itself.
Remote port forwarding does the opposite: it forwards traffic coming to a remote
port to a specified local port.
For example, if you issue the command
ssh2 -R 1234:localhost:23 username@host
all traffic which comes to port 1234 on the server (host) will be forwarded
to port 23 on the client (localhost).
It is important to realize that if you have three hosts, client,
sshdserver, and appserver, and you forward the traffic coming to the
client's port x to the appserver's port y, only the
connection between the client and sshdserver will be secured. See
Figure Forwarding to a third host. The
command you use would be something like the following:
ssh2 -L x:appserver:y username@sshdserver
![tunnel2-2.gif]()
Figure : Forwarding to a third host
Forwarding FTP
With SSH Secure Shell version 3.0 and above it is possible to easily
forward FTP connections by using a command with the following syntax:
ssh2 -L ftp/x:ftpdserver:y username@sshdserver
FTP forwarding is an extension to the generic port forwarding mechanism. The FTP
control channel can be secured by using generic port forwarding, but since the
FTP protocol requires creating separate TCP connections for the files to be
transferred, all the files would be transferred unencrypted when using generic port
forwarding, as these separate TCP connections would not be forwarded automatically.
To protect also the transferred files, use FTP forwarding instead. It works
similarly to generic port forwarding, except that the FTP forwarding code
monitors the forwarded FTP control channel and dynamically creates new port
forwardings for the data channels as they are requested. To see exactly how this
is done, two different cases need to be examined: the active mode and the
passive mode of the FTP protocol.
FTP in passive mode
In passive mode, the FTP client sends the command 'PASV' to the server, which reacts
by opening a listener port for the data channel and sending the IP address and port
number of the listener as a reply to the client. The reply is of the form '227 Entering
Passive Mode (10,1,60,99,6,12)'.
When the Secure Shell client notices the reply to the PASV command, it will
create a local port forwarding to the destination mentioned in the reply. After
this the client will rewrite the IP address and port in the reply to point to
the listener of the newly created local port forwarding (which exists always in
a local host address, 127.0.0.1) and pass the reply to the FTP client. The FTP
client will open a data channel based on the reply, effectively tunneling the
data through the SSH connection, to the listener the FTP server has opened. The
net effect is that the data channel is secure all the way except from the Secure
Shell server to the FTP server, if they are on different machines. This sequence
of events happens automatically for every data channel.
Since the port forwarding is opened to a local host address, the FTP client must be run
on the same machine as the Secure Shell client if passive mode is used.
FTP in active mode
In active mode, the FTP client creates a listener on a local port, for a data
channel from the FTP server to the FTP client, and requests the channell by
sending the IP address and the port number to the FTP server in a command of the
following form: 'PORT 10,1,60,99,6,12'. The Secure Shell client intercepts this
command and creates a remote port forwarding from the Secure Shell server's
localhost address to the address and port specified in the PORT command.
After creating the port forwarding, the Secure Shell client rewrites the address
and port in the PORT command to point to the newly opened remote forwarding on
the Secure Shell server and sends it to the FTP server. Now the FTP server will
open a data channel to the address and port in the PORT command, effectively
forwarding the data through the SSH connection. The Secure Shell client passes
the incoming data to the original listener created by the FTP client. The net
effect is that the data channel is secure the whole way except from the Secure
Shell client to the FTP client. This sequence of events happens automatically
for every data channel.
Since the port forwarding is made to a local host address on the Secure Shell
client machine, the FTP client must be run in the same host as the Secure Shell
client if passive mode is used.
Where end-to-end encryption of FTP data channels is desired, the FTP server and
Secure Shell server need to reside on the same host, and the FTP client and the
Secure Shell client will likewise need to reside on the same host. If this is
the case, both active or passive mode can be used.
Note: Consider using sftp2 or scp2 instead of FTP
forwarding to secure file transfers. It will require less configuration than FTP
forwarding, since the SSH Secure Shell server already has sftp-server2 as a
subsystem, and sftp2 and scp2 clients are included in the distribution. Managing
remote user restrictions on the server machine will be easier, since you do not
have to do it also for FTP.