Server Administration

  Home arrow Server Administration arrow Page 2 - SSH Case Studies: Gateway Hosts

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

    Table of Contents:
  • SSH Case Studies: Gateway Hosts
  • 11.4.2 Using SCP Through a Gateway



    SSH Case Studies: Gateway Hosts - 11.4.2 Using SCP Through a Gateway

    (Page 2 of 2 )

    Recall that the command:

    $ scp ... S:file ...

    actually runs ssh in a subprocess to connect to S and invoke a remote scp server. [3.7] Now that we’ve gotten ssh working from client C to server S, you’d expect that scp would work between these machines with no further effort. Well, it almost does, but it wouldn’t be software if there weren’t a small problem to work around, in this case authentication. You can’t provide a password or passphrase to the second ssh program, since there is no pseudo-terminal on the first ssh session—ssh requires a terminal for user input. So, you need a form of authentication that doesn’t require user input: either hostbased, or public-key authentication with agent forwarding. Host-based works as is, so if you plan to use it, you can skip to the next section. Public-key authentication, however, may have a problem: some versions of scp run ssh with the –a switch to disable agent forwarding. [] You need to reenable agent forwarding for this to work, and this is surprisingly tricky.

    Normally, you could turn on agent forwarding in your client configuration file:

    # ~/.ssh/config on client C, but this
    ForwardAgent yes

    but this doesn’t help because as it happens, the –a on the command line takes precedence. Alternatively, you might try the –o option of scp, which can pass along options to ssh, such as –o ForwardAgent yes. But in this case, scp places the –a after any –o options it passes where it takes precedence, so that doesn’t work either.

    There is a solution, though. scp has a –S option to indicate a path to the SSH client program it should use, so you create a “wrapper” script that tweaks the SSH command line as needed, and then make scp use it with –S. Place the following script in an executable file on client C—say, ~/bin/ssh-wrapper:

    exec '/usr/bin/ssh', map {$_ eq '-a' ? () : $_} @ARGV;

    This runs the real ssh, removing –a from the command line if it’s there. Now, give your scp a command like this:

    scp -S ~/bin/ssh-wrapper ...S:file...

    and it should work.

    11.4.3 Another Approach: SSH-in-SSH (Port Forwarding)

    Instead of using a forced command, here’s another way to connect by SSH through a gateway: forward a port on client C to the SSH server on S, using an SSH session from C to G, and then run a second SSH session through the first (see Figure 11-13).

    Figure 11-13. Forwarded SSH connection through a proxy gateway

    That is:

    # Execute on client C
    $ ssh -L2001:S:22 G

    # Execute on client C in a different shell
    $ ssh -p 2001 -o HostKeyAlias=S localhost

    This connects to server S by carrying the second SSH connection (from C to S) inside a port-forwarding channel of the first (from C to G). Note the use ofHostKeyAlias, so ssh will look up S’s host key with the name “S.” Otherwise, it would try to use the key for “localhost,” which would be the wrong key.

    You can make this more transparent by creating a nickname S in your client configuration file:

    # ~/.ssh/config on client C
    Host S
    Hostname localhost
    Port 2001
    HostKeyAlias S

    Now the earlier commands become:

    # Execute on clientC
    $ ssh -L2001:S:22 G

    # Execute on client C in a different shell
    $ ssh S

    Because this technique requires a separate, manual step to establish the port forwarding, it is less transparent than the one in [11.4.1]. However, it has some advantages. If you plan to use port or X forwarding between C and S with the first method, it’s a little complicated. scp not only gives the –a switch to ssh to turn off agent forwarding, but also it gives –x and –o “ClearAllForwardings yes”, turning off X and port forwarding. So, you need to modify the earlier wrapper script to remove these unwanted options as well. [11.4.2] Then, for port forwarding you need to set up a chain of forwarded ports that connect to one another. For example, to forward port 2017 on client C to port 143 (the IMAP port) on server S:

    # ~/.ssh/config on client C
    hostname G
    user gilligan

    # ~/.ssh/authorized_keys on gateway G
    command="ssh -L1234:localhost:143 skipper@S" ...key...

    # Execute on client C
    $ ssh -L2017:localhost:1234 S

    This works, but it’s difficult to understand, error-prone, and fragile: if you trigger the TIME_WAIT problem [], you have to edit files and redo the tunnel just to pick a new ephemeral port to replace 1234.

    Using the SSH-in-SSH technique instead, your port and X-forwarding options operate directly between client C and server S in the usual, straightforward manner. The preceding example becomes:

    # ~/.ssh/config on client C
    Hostname localhost
    Port 2001
    HostKeyAlias S

    # Execute on client C
    $ ssh -L2001:S:22 G

    # Execute on client C in a different shell
    $ ssh -L2017:localhost:143 S

    This final command connects to server S, forwarding local port 2017 to the IMAP port on S.

    Please check back next week for the continuation of this article.

    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