Server Administration

  Home arrow Server Administration arrow Page 2 - SSH Case Studies: Network Address Tran...

SSH Case Studies: Network Address Translation
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating:  stars stars stars stars stars / 0

    Table of Contents:
  • SSH Case Studies: Network Address Translation
  • 11.2.7 All About Data Connections



    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:

    1. The usual method
    2. Passive-mode transfers
    3. 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. The usual method of file 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
    Connected to
    220 FTP server (SunOS 5.7) ready.
    ---> USER res
    331 Password required for res.
    ---> 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 (,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, 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.
    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