Re: How to create an ssh chain A->B->C to do http over ssh across the chain?

[Kevin Buhr <buhr+debian@asaurus.net>]

Mitchell Laks <mlaks@post.harvard.edu> writes:
>
> Here is the situation. You have machines A->B->C. You want to create a ssh tunnel directly
> from A to C.
>
> Machine A can see machine B and machine B can see C, but A can't see C directly.
> A and B are on a local network and only B has 'limited net access'.

I tested the following two solutions, and they seem to work.

First, running the following on host A:

        hosta$ ssh -L 8080:localhost:8080 B ssh -D 8080 yourlogin@C.com

will set things up so that localhost connections on A to port 8080
will be forwarded over an SSH connection to port 8080 on host B.  The
second "ssh" command running on B, meanwhile, will then act as a SOCKS
server on port 8080, accepting connections forwarded from A,
demultiplexing the SOCKS stream, and managing connections as if they
originated from C.

Note that you could do:

        hosta$ ssh -L 8080:localhost:8080 B ssh -N -D 8080 yourlogin@C.com

(i.e., specifying the -N flag) instead, but I had trouble with the
second "ssh" connection sticking around after the first died when I
tested it, so the former might be better, even though it ties up a terminal.

Note also that, using this method, other users on host B could also
connect to local port 8080 and use that socks server to manage
connections originating from host C.  This may or may not be a
problem.

Second, another possibility, which may be more flexible, would be to
set up an SSH tunnel from A to B to accomodate a direct SSH connection
from A to C.  That is, the command (run on host A):

        hosta$ ssh -NL 8022:C.com:22 B &

will set things up so that local connections to port 8022 will be
forwarded over the tunnel B to become a connection from B to port 22
on C.  Now, if you run the command (on host A):

        hosta$ ssh -o UserKnownHostsFile=/dev/null \
        >        -o StrictHostKeyChecking=no -ND 8080 -p 8022 localhost

that will connect to the SSH server on C providing a local SOCKS
server on A.  Note that the first SSH tunnel is being used only for
its tunnelling side effect, not security.  In fact, the traffic
between B and C will travel "in the clear", but the traffic here is
from the second SSH connection which is separately encrypted and so safe.

The two "-o" options here are to prevent SSH from verifying and
storing the host key for this connection.  You are actually connecting
to host C, but it looks to SSH like you are connecting to "localhost",
so SSH will store C's host key as if it's the localhost key, and
you'll get warnings and errors about changed keys in the future.  This
would open the door to a man-in-the-middle attack, but it's probably
not a big concern for your purposes.

-- 
Kevin Buhr <buhr+debian@asaurus.net>