SSH Case Studies: Network Address Translation - 11.2.7 All About Data Connections
(Page 2 of 2 )
Ask most SSH users about forwarding the FTP data connection, and they’ll respond, “Sorry, it’s not possible.” Well, it is possible. The method we’ve discovered is obscure, inconvenient, and not usually worth the effort, but it works. Before we can explain it, we must first discuss the three major ways that FTP accomplishes file transfers between client and server:
The usual method
Transfers using the default data ports
We’ll just touch briefly on the first two, since we’ve already discussed them; we’ll just amplify with a bit more detail. Then we’ll discuss the third mode, which is the least known and the one you need if you really, really want to forward your FTP data connections.
188.8.131.52 The usual method of ﬁle transfer
Most FTP clients attempt data transfers in the following way. After establishing the control connection and authenticating, the user issues a command to transfer a file. Suppose the command is get fichier.txt, which asks to transfer the file fichier.txt from the server to the client. In response to this command, the client selects a free local TCP socket, call it C, and starts listening on it. It then issues a PORT command to the FTP server, specifying the socket C. After the server acknowledges this, the client issues the command RETR fichier.txt, which tells the server to connect to the previously given socket (C) and send the contents of that file over the new data connection. The client accepts the connection to C, reads the data, and writes it into a local file also called fichier.txt. When done, the data connection is closed. Here is a transcript of such a session:
$ ftp -d aaor.lionaka.net Connected to aaor.lionaka.net. 220 aaor.lionaka.net FTP server (SunOS 5.7) ready. ---> USER res 331 Password required for res. Password: ---> PASS XXXX 230 User res logged in. ---> SYST 215 UNIX Type: L8 Version: SUNOS Remote system type is UNIX. Using binary mode to transfer files. ftp> get fichier.txt local: fichier.txt remote: fichier.txt ---> TYPE I 200 Type set to I. ---> PORT 219,243,169,50,9,226 200 PORT command successful. ---> RETR fichier.txt 150 Binary data connection for fichier.txt (184.108.40.206,2530) (10876 bytes). 226 Binary Transfer complete. 10876 bytes received in 0.013 seconds (7.9e+02 Kbytes/s) ftp> quit
Note thePORT command,PORT 219,243,169,50,9,226. This says the client is listening on IP address 220.127.116.11, port 2530 = (9<8)+226; the final two integers in the comma-separated list are the 16-bit port number represented as two 8-bit bytes, most significant byte first. The server response beginning with “150” confirms establishment of the data connection to that socket. What isn’t shown is that the source port of that connection is always the standard FTP data port, port 20 (remember that FTP servers listen for incoming control connections on port 21).
There are two important points to note about this process:
The data connection socket is chosen on the fly by the client. This prevents forwarding, since you can’t know the port number ahead of time to forward it with SSH. You can get around this problem by establishing the FTP process “by hand” using telnet. That is, choose a data socket beforehand and forward it with SSH, telnet to the FTP server yourself, and issue all the necessary FTP protocol commands by hand, using your forwarded port in thePORTcommand. But this can hardly be called convenient.
Remember that the data connection is made in the reverse direction from the control connection; it goes from the server back to the client. As we discussed earlier in this chapter, the usual workaround is to use passive mode.
Please check back in two weeks for the next part of the series.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.