SSH Case Studies: More on the Passive Mode - 11.2.8 Forwarding the Data Connection
(Page 2 of 2 )
With all the foregoing discussion in mind, here we simply state the sequence of steps to set up data-connection forwarding. One caveat is that SSH must request address reuse from TCP for forwarded ports. Tectia and OpenSSH do this already, but not all SSH clients may.
Another issue is that the operating system in which the FTP client is running must allow a process to listen on a socket already in use as the endpoint of an existing connection. Some donít. To test this, try an FTP data transfer on the default data ports without SSH, just by using ftp as usual but giving the sendport command before ls, get, or whatever. If you get:
ftp: bind: Address already in use
then your operating system probably wonít cooperate. There may be a way to alter this behavior; check the operating system documentation. Figure 11-7 illustrates the following steps:
Start an SSH connection to forward the control channel as shown earlier in this chapter, and connect with the FTP client. Make sure that passive mode is off. For OpenSSH:
client% ssh -f -n -L2001:localhost:21 server sleep 10000 &
or for Tectia:
client% ssh -f -n -L2001:localhost:21 server
client% ftp localhost 2001 Connected to localhost 220 server FTP server (SunOS 5.7) ready. Password: 230 User res logged in. ftp> sendport Use of PORT cmds off. ftp> passive
Figure 11-7. Forwarding the FTP data connection
Passive mode on. ftp> passive Passive mode off.
Note that we are using localhost as the forwarding target here, despite our earlier advice. Thatís OK, because there wonít be any PORT or PASV commands with addresses that can be wrong.
Now, we need to determine the real and proxy default data ports for the FTP client. On the client side, you can do this with netstat:
client% netstat -n | grep 2001 tcp 0 0 client:2001 client:3175 ESTABLISHED tcp 0 0 client:3175 client:2001 ESTABLISHED
This shows that the source of the control connection from the FTP client to SSH is port 3175. You can do the same thing on the server side, but this time you need to know whatís connected to the FTP server port (netstat Ėn | egrep Ď\<21\>í), and there may be many things connected to it. If you have a tool like lsof, itís better to find out the pid of the ftpd or sshd serving your connection and use lsof Ėp <pid> to find the port number. If not, you can do a netstat before connecting via FTP and then one right afterward, and try to see which is the new connection. Letís suppose youíre the only one using the FTP server, and you get it this way:
server% netstat | grep ftp tcp 0 0 server:32714 server:ftp ESTABLISHED tcp 0 0 server:ftp server:32714 ESTABLISHED
So now, we have the FTP clientís default data port (3175), and the source port of the forwarded control connection to the FTP server (32714), which weíll call the proxy default data port; it is what the FTP server thinks is the clientís default data port.
Now, forward the proxy default data port to the real one:
Now, try a data-transfer command with ftp. If all goes well, it should work once, then fail with this message from the FTP server:
425 Can't build data connection: Address already in use.
(Some FTP servers return that error immediately; others will retry several times before giving up, so it may take a while for that error to appear.) If you wait for the serverís 2MSL timeout period, you can do another single data transfer. You can use netstat to see the problem and track its progress:
server% netstat | grep 32714
The first two lines show the established control connection on port 21; the third one shows the old data connection to port 20, now in the TIME_WAIT state. When that disappears, you can do another data-transfer command.
And there you have it: you have forwarded an FTP data connection through SSH. You have achieved the Holy Grail of FTP with SSH, though perhaps you agree with us and Sir Gawain that ďitís only a model.Ē Still, if youíre terribly concerned about your data connections, have no other way to transfer files, can afford to wait a few minutes between file transfers, and are quite lucky, then this will work. It also makes a great parlor trick at geek parties.
Please check back next week 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.