Server Administration

  Home arrow Server Administration arrow SSH Case Studies: The FTP Protocol
SERVER ADMINISTRATION

SSH Case Studies: The FTP Protocol
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating:  stars stars stars stars stars / 0
    2012-06-13

    Table of Contents:
  • SSH Case Studies: The FTP Protocol
  • 11.2.4 Forwarding the Control Connection

  •  
     

    SEARCH CODEWALKERS

    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:

    1. 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.
    2. 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:

    $ ftp -d aaor.lionaka.net
    Connected to aaor.lionaka.net.
    220 aaor.lionaka.net FTP server (SunOS 5.7) ready.
    ---> SYST
    215 UNIX Type: L8 Version: SUNOS
    Remote system type is UNIX.
    Using binary mode to transfer files.
    ftp> user res
    ---> USER res
    331 Password required for res.
    Password:
    ---> PASS XXXX
    230 User res logged in.
    ftp> cd rep
    ---> CWD rep
    250 CWD command successful.
    ftp> cd utopia
    ---> CWD utopia
    550 utopia: No such file or directory.
    ftp> quit
    ---> QUIT
    221 Goodbye.

    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.


    Figure 11-1. Basic FTP operations: control connection and active- versus passive-mode transfers

    More Server Administration Articles
    More By O'Reilly Media

    blog comments powered by Disqus
    Antalya eskort Antalya escort bayanlar izmir escort

    SERVER ADMINISTRATION ARTICLES

    - SSH Case Studies: Gateway Hosts
    - SSH Case Studies: More on Pine and SSH
    - SSH Case Studies: Pine and IMAP
    - SSH Case Studies: More on the Passive Mode
    - SSH Case Studies: Network Address Translation
    - SSH Case Studies: The Passive Mode
    - SSH Case Studies: The FTP Protocol
    - SSH Case Studies: Batch Jobs, FTP and SSH
    - SSH Case Studies: Agents and Authentication
    - SSH Case Studies
    - Server Responses to Client Communication
    - Authentication in Client/Server Communication
    - Client/Server Communication
    - Understanding Awk in the UNIX Shell
    - Stream Editor in the UNIX Shell

    Developer Shed Affiliates

     



    © 2003-2014 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap