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 Tectia Client which will forward the connection to the endpoint where a Secure Shell server is running.
The typical use case is that 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 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 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
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 Tectia Connections 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
<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
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 Tectia Server already has
as a subsystem, and
scpg3 clients are
included with 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.
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
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 Tectia Client if passive mode is used.
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:
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
After creating the tunnel, the Connection Broker rewrites the address and port
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
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 Tectia Client to the FTP
client. This sequence of events takes place automatically for every data
Since the tunnel is made to a localhost address on the 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 Tectia Client will likewise need to reside on the same host.
Tunneling FTP in active mode is not guaranteed to work in all setups. If possible, use the passive mode when tunneling FTP connections.