Non-Transparent FTP Tunneling

Non-transparent FTP tunneling is an extension to the generic tunneling mechanism. Unlike generic tunneling (port forwarding) mechanism, non-transparent FTP tunneling secures the transferred files, in addition to the FTP control channel. The FTP tunneling code monitors the tunneled FTP control channels and dynamically creates new tunnels for the data channels as they are requested.

When non-transparent FTP tunneling is used, tunnels are created from local client ports to remote servers. The FTP client is configured to connect to SSH Tectia Client which will forward the connection to the endpoint where a Secure Shell server is running.

The typical use case is that SSH Tectia Client is located on the same host as the FTP client; and the FTP server is on the same host as the Secure Shell server. However, other configurations are also supported, but it is worth noticing that the connection is encrypted only between SSH Tectia Client and the Secure Shell server.

Non-transparent FTP tunneling can be requested on the command line, or enabled and defined in the Connection Broker configuration. The configured non-transparent FTP tunneling uses connection profiles, that are defined on SSH Tectia Client.

On command-line, FTP tunneling can be used for both local and remote tunnels. Non-transparent FTP-tunneling is started by entering a sshg3 command with the following syntax:

sshclient$ sshg3 -L ftp/1234:localhost:21 username@sshserver

For information on the sshg3 command, see the sshg3(1) man page.

The FTP tunneling settings can be made in the Connection Broker Configuration GUI, under Connection Profiles → Tunneling for each profile. See Defining Tunneling.

FTP tunnels can also be defined for connection profiles in the Connection Broker configuration file. The following is an example from the Connection Broker configuration file ssh-broker-config.xml:

<profiles>
  <profile id="id1" host="sshserver.example.com"
  ...
    <tunnels>
      <local-tunnel type="FTP" 
                    listen-port="1234"
                    dst-host="127.0.0.1"
                    dst-port="21"
                    allow-relay="NO" />
      ...  
    </tunnels>
  </profile>
</profiles>

An FTP connection can then be made with the following (example) commands:

sshclient$ ftp 
ftp$ open localhost 1234

The FTP connection to port 1234 on client is now tunneled to port 21 on the Secure Shell server.

As an alternative to FTP tunneling, you can use the sftpg3 or scpg3 clients for secure file transfers. These clients can be used on command line or in scripts and they require less configuration than FTP tunneling, since SSH Tectia Server already has sft-server-g3 as a subsystem, and sftpg3 and scpg3 clients are included with SSH Tectia Client. Managing remote user restrictions on the server machine will be easier, since you do not have to do it also for FTP.

To understand exactly how FTP tunneling is done, two different cases need to be examined: the active mode and the passive mode of the FTP protocol.

Tunneling 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 Connection Broker notices the reply to the PASV command, it will create a local port forwarding to the destination mentioned in the reply. After this the Connection Broker 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 localhost 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 Secure Shell connection, to the listener the FTP server has opened. The net effect is that the data channel is secured all the way except from the Secure Shell server to the FTP server if they are on different machines. This sequence of events takes place automatically for every data channel.

Since the tunnel is opened to a localhost address, the FTP client must run on the same machine as SSH Tectia Client if passive mode is used.

Tunneling 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 channel 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 Connection Broker intercepts this command and creates a remote port forwarding from the localhost address of the Secure Shell server to the address and port specified in the PORT command.

After creating the tunnel, the Connection Broker 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 Secure Shell connection. The Connection Broker 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 SSH Tectia Client to the FTP client. This sequence of events takes place automatically for every data channel.

Since the tunnel is made to a localhost address on the SSH Tectia Client machine, the FTP server must be run on the same host as the Secure Shell server if active 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 SSH Tectia Client will likewise need to reside on the same host.

	Note
	Tunneling FTP in active mode is not guaranteed to work in all setups. If possible, use the passive mode when tunneling FTP connections.