Server Administration

  Home arrow Server Administration arrow Page 2 - SSH Case Studies: The FTP Protocol
SERVER ADMINISTRATION

SSH Case Studies: The FTP Protocol
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating:  stars stars stars stars stars / 0
    2012-06-13

    Table of Contents:
  • SSH Case Studies: The FTP Protocol
  • 11.2.4 Forwarding the Control Connection

  •  
     

    SEARCH CODEWALKERS

    SSH Case Studies: The FTP Protocol - 11.2.4 Forwarding the Control Connection


    (Page 2 of 2 )

    Since the FTP control connection is just a single, persistent TCP connection to a well-known port, you can forward it through SSH. As usual, the FTP server machine must be running an SSH server, and you must have an account on it that you may access via SSH (see Figure 11-2).


    Figure 11-2. Forwarding the Control Connection

    Suppose you are logged into the machine client and want to connect securely to an FTP server on the machine server. To forward the FTP control connection, run a port-forwarding command on client:*

    client% ssh -L2001:server:21 server

    Then, to use the forwarded port:

    client% ftp localhost 2001
    Connected to localhost
    220 server FTP server (SunOS 5.7) ready.
    Password:
    230 User res logged in.
    ftp> passive
    Passive mode on.
    ftp> ls

    ... and so on

    There are two important things to notice about the commands we just recommended. We will discuss each.

    1. The target of the forwarding is server, not localhost.
    2. The client uses passive mode.

    11.2.4.1 Choosing the forwarding target

    We chose server as the target of our forwarding, not localhost (i.e., we didn’t use –L2001:localhost:21). This is contrary to our previous advice, which was to use localhost where possible as the forwarding target. [9.2.8] Well, that technique isn’t advisable here. Here’s what can happen if you do:

    client% ftp localhost 2001
    Connected to client
    220 client FTP server (SunOS 5.7) ready.
    331 Password required for res.
    Password:
    230 User res logged in.
    ftp> ls
    200 PORT command successful.
    425 Can't build data connection: Cannot assign requested address.
    ftp>

    The problem is a bit obscure but can be revealed by an execution trace of the FTP server as it responds to the ls command. The following output was produced by the Linux strace command:*

    so_socket(2, 2, 0, "", 1) = 5
    bind(5, 0x0002D614, 16, 3) = 0
    AF_INET name = 127.0.0.1 port = 20
    connect(5, 0x0002D5F4, 16, 1) Err#126 EADDRNOTAVAIL

    AF_INET name = 192.168.10.1 port = 2845
    write(1, " 4 2 5 C a n ' t
    b u".., 67) = 67

    The FTP server is trying to make a TCP connection to the correct client address but from the wrong socket: the ftp-data port on its loopback address, 127.0.0.1. The loopback interface can talk only to other loopback addresses on the same machine. TCP knows this and responds with the error “address not available”
    (EADDRNOTAVAIL). The FTP server is being careful to originate the data connection from the same address to which the client made the control connection. Here, the control connection has been forwarded through SSH; so to the FTP server, it appears to come from the local host. And because we used the loopback address as the forwarding target, the source address of that leg of the forwarded path (from sshd to ftpd)is also the loopback address. To eliminate the problem, use the server’s nonloopback IP address as the target; this causes the FTP server to originate data connections from that address.

    You might try to solve this problem using passive mode, since then the server wouldn’t originate any connections. But if you try:

    ftp> passive
    Passive mode on.
    ftp> ls
    227 Entering Passive Mode (127,0,0,1,128,133)
    ftp: connect: Connection refused
    ftp>

    In this case, the failure is a slightly different manifestation of the same problem. This time, the server listens for an incoming data connection from the client, but again, it thinks the client is local, so it listens on its loopback address. It sends this socket (address 127.0.0.1, port 32901) to the client, and the client tries to connect to it. But this causes the client to try to connect to port 32901 on the client host, not the server! Nothing is listening there, of course, so the connection is refused.

    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

    SERVER ADMINISTRATION ARTICLES

    - 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