Server Administration

  Home arrow Server Administration arrow SSH Case Studies: The Passive Mode

SSH Case Studies: The Passive Mode
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating:  stars stars stars stars stars / 0

    Table of Contents:
  • SSH Case Studies: The Passive Mode
  • 11.2.5 FTP, Firewalls, and Passive Mode



    SSH Case Studies: The Passive Mode

    (Page 1 of 2 )

    In this fifth part of a nineteen-part article series on SSH, you will learn about the benefits of putting a client in passive mode. This is particularly important in reference to the interactions between FTP, SSH, and firewalls. 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). Using passive mode

    Note that we had to put the client into passive mode. You will see later that passive mode is beneficial for FTP in general, because it avoids some common firewall and NAT problems. Here, however, it’s used because of a specific FTP/SSH problem; if you didn’t, here’s what happens:

    $ ftp -d localhost 2001
    Connected to localhost.
    220 server FTP server (SunOS 5.7) ready.
    ---> USER res
    331 Password required for res.
    ---> PASS XXXX
    230 User res logged in.
    ftp> ls
    ---> PORT 127,0,0,1,11,50
    200 PORT command successful.
    ---> LIST
    425 Can't build data connection: Connection refused.

    This is a mirror image of the problem we saw when localhost was the forwarding target, but this time it happens on the client side. The client supplies a socket for the server to connect to, and since it thinks the server is on the local host, that socket is on the loopback address. This causes the server to try connecting to its local host instead of the client machine.

    Passive mode can’t always be used: the FTP client or server might not support it, or server-side firewall/NAT considerations may prevent it (you’ll see an example of that shortly). If so, you can use theGatewayPortsfeature of SSH and solve this problem as we did the previous one: use the host’s real IP address instead of the loopback. To wit:

    client% ssh -g -L2001:server:21 server

    Then connect to the client machine by name, rather than to localhost:

    client% ftp client 2001

    This connects to the SSH proxy on the client’s nonloopback address, causing the FTP client to listen on that address for data connections. The –g option has security implications, however. []

    Of course, as we mentioned earlier, it’s often the case that active-mode FTP isn’t usable. It’s perfectly possible that your local firewall/NAT setup requires passive mode, but you can’t use it. In that case, you’re just out of luck. Put your data on a diskette and contribute to the local bicycle-courier economy.

    The various problems we have described, while common, depend on your particular Unix flavor and FTP implementation. For example, some FTP servers fail even before connecting to a loopback socket; they see the client’sPORTcommand and reject it, printing “illegal PORT command”. If you understand the reasons for the various failure modes, however, you will learn to recognize them in different guises. The “PASV port theft” problem

    Trying to use FTP with SSH can be sort of like playing a computer dungeon game: you find yourself in a twisty maze of TCP connections, all of which look alike and none of which seem to go where you want. Even if you follow all of our advice so far, and understand and avoid the pitfalls we’ve mentioned, the connection might still fail:

    ftp> passive
    Passive mode on.
    ftp> ls
    connecting to
    Connected to port 6670
    425 Possible PASV port theft, cannot open data connection.
    ! Retrieve of folder listing failed

    Assuming you don’t decide to give up entirely and move into a less irritating career, you may want to know, “What now?” The problem here is a security feature of the FTP server, specifically the popular wu-ftpd from Washington University. (See http:// This feature might be implemented in other FTP servers, but we haven’t seen it.) The server accepts an incoming data connection from the client, then notices that its source address isn’t the same as that of the control connection (which was forwarded through SSH and thus comes from the server host). It concludes that an attack is in progress! The FTP server believes someone has been monitoring your FTP control connection, seen the server response to thePASVcommand containing the listening socket, and jumped in to connect to it before the legitimate client can do so. So, the server drops the connection and reports the suspected “port theft” (see Figure 11-3).

    There’s no way around this problem but to stop the server from performing this check. It’s a problematic feature to begin with, since it prevents not only attacks, but also legitimate FTP operations. For example, passive-mode operation was originally intended to allow an FTP client to effect a file transfer between two remote servers

    Figure 11-3. "PASV port theft"

    directly, rather than first fetching the file to the client and then sending it to the second server. This isn’t a common practice, but it is part of the protocol design, and the “port theft” check of wu-ftpd prevents its use. You can turn it off by recompiling wu-ftpd without FIGHT_PASV_PORT_RACE (use configure --disable-pasvip). You can also leave the check on but allow certain accounts to use alternate IP addresses for data connections, with the pasv-allow and port-allow configuration statements. See the ftpaccess(5) manpage for details. Note that these features are relatively recent additions to wu-ftpd and aren’t in earlier versions.

    More Server Administration Articles
    More By O'Reilly Media

    blog comments powered by Disqus


    - 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-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap