SSH Case Studies: The FTP Protocol

(Page 1 of 2 )

In this fourth article of a nineteen-part series on SSH, we'll take a close look at FTP protocol. This will assist you in understanding the issues that can crop up between FTP and the secure shell. This article is excerpted from chapter 11 of the book SSH, The Secure Shell: The Definitive Guide, Second Edition, written by Daniel J. Barrett, Richard E. Silverman and Robert G. Byrnes (O'Reilly; ISBN-10: 0596008953).

11.2.3 The FTP Protocol

To understand the problems between FTP and SSH, you need to understand a bit about the FTP protocol. Most TCP services involve a single connection from client to server on a known, server-side port. FTP, however, involves multiple connections in both directions, mostly to unpredictable port numbers:

A single control connection for carrying commands from the client and responses from the server. It connects on TCP port 21 and persists for the entire FTP session.

A number of data connections for transferring files and other data, such as directory listings. For each file transfer, a new data connection is opened and closed, and each one may be on a different port. These data connections may come from the client or the server.

Let’s run a typical FTP client and view the control connection. We’ll use debug mode (ftp –d) to make visible the FTP protocol commands the client sends on the control connection, since they aren’t normally displayed. Debug mode prints these commands preceded by “--->”. For example:

---> USER res

You’ll also see responses from the server, which the client prints by default. These are preceded by a numerical code:

230 User res logged in.

Here’s a session in which the user res connects to an FTP server, logs in, and attempts to change directory twice, once successfully and once not:

The control connection can be secured by standard port forwarding because it is on a known port (21). [9.2] In contrast, the destination port numbers for data connections are generally not known in advance, so setting up SSH forwarding for these connections is far more difficult. There’s a second standard port number associated with FTP, the ftp-data port (20). But this is only the source port for data connections coming from the server; nothing ever listens on it.

Surprisingly, the data connections generally go in the opposite direction from the control one; that is, the server makes a TCP connection back to the client in order to transfer data. The ports on which these connections occur can be negotiated dynamically by the FTP client and server, and doing so involves sending explicit IP address information inside the FTP protocol. These features of usual FTP operation can cause difficulties when forwarding SSH connections and in other scenarios involving firewalls or NAT.

An alternative FTP mode, called passive mode, addresses one of these problems: it reverses the sense of the data connections so that they go from the client to the server. Passive mode is a matter of FTP client behavior, and so is determined by a client setting. The behavior of setting up data connections from the server to the client, which we will call active-mode FTP, is traditionally the default in FTP clients, although that’s changing. With a command-line client, the passive command switches to passive mode. The internal command that the client sends the server to tell it to enter passive mode isPASV. We discuss specific problems, and how passive mode solves them, in upcoming sections. Figure 11-1 summarizes the workings of passive and active FTP.