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).
184.108.40.206 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. Password: ---> 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. ftp>
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. [220.127.116.11]
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.
18.104.22.168 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 192.168.10.1:6670 Connected to 192.168.10.1 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:// www.wu-ftpd.org/. 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.