Server Administration

  Home arrow Server Administration arrow Page 2 - SSH Case Studies: More on the Passive ...

SSH Case Studies: More on 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: More on the Passive Mode
  • 11.2.8 Forwarding the Data Connection



    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:

    1. 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.
      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.
    2. 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.
    3. Now, forward the proxy default data port to the real one:

      # OpenSSH
      client% ssh -f -n -R32714:localhost:3175 server sleep 10000 &

      # Tectia
      client% ssh -f -R32714:localhost:3175 server

      If, as we mentioned earlier, you don’t replace sshd or run a second one, then you’d use the modified ssh on the server in the other direction, like this:

      server% ./ssh -f -n -L32714:localhost:3175 client sleep 10000 &
    4. 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 32768 0 32768 0 ESTABLISHED 32768 0 32768 0 ESTABLISHED 32768 0 32768 0 TIME_WAIT

    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.
    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