[kwlug-disc] ssh and port forwarding

[Rashkae]

Rashkae wrote:
> Rashkae wrote:
>> Robert P. J. Day wrote:
>>>   i have the following scenario:
>>>
>>>   host1  <---------->  host2  <--------->  host3
>>>   (ME)
>>>
>>> i want to be able to do the following from host1:
>>>
>>>   1) ssh directly and normally to host2 (trivial)
>>>   2) using host2 as a gateway, ssh from host1 to get to host3
>>>
>>> from the perspective of host1, host2 will be visible (through a
>>> corporate VPN, but still visible).  host3, on the other hand, will be
>>> "hiding" behind host2 on a totally different and internal network, so
>>> i have to use someone else as a gateway -- direct ssh from host1 to
>>> host3 is out of the question.
>>>
>>>   assume the normal stuff: that host1 has an ssh client, and both
>>> host2 and host3 are running an ssh server of some kind (probably
>>> dropbear, actually), and that the ssh server on host2 is set up to do
>>> port forwarding.
>>>
>>>   i've seen two solutions (local and remote forwarding) that involves
>>> doing all the work on host1 but i'd rather not do that -- i'd rather
>>> keep life on host1 simple, and centralize the forwarding configuration
>>> at host2.  so, as i read it, the direct ssh from host1 to host2 will
>>> still work fine, but what do i do at host2?
>>>
>>>   since host2 *will* be running dropbear, as i read, first, on host2,
>>> i'll invoke:
>>>
>>>    # dropbear -a
>>>
>>> so that dropbear is running in port forwarding mode.
>>>
>>>   in addition, on host2, i'll have to run:
>>>
>>>   # dbclient -L 1234:localhost:22 host3
>>>
>>> does that make sense?  so i can ssh from host1 to host2 normally, but
>>> if i want to sh from host1 to host3, i'll invoke:
>>>
>>>   $ ssh host2 1234
>>>
>>> which will get me to host2, which will then forward me on to port 22
>>> on host3.  am i on the right path here?  thanks.
>>>
> 
> After typing all of that previous message, I just realized what you are
> trying to do.. (duh moment for the day), and yes, you are absolutely
> correct.  You can just ignore everything I wrote earlier.
> 

One interesting side effect of this, however, is you will be double
encrypting everything between host2 and host3, since the port forwarding
is being done between those two points with ssh.  After all, what's the
point of having 2Ghz Cpu's all over the place if you don't exercise them
from time to time.

You would get the same end result if, when you ssh into host2, you use
iptables (or equivalent) to forward the port, rather than ssh.

iptables -t nat -A PREROUTING -p tcp -d Inet_Ip_Address --dports 1234 -j
DNAT --to-destination host3:22

If host2 doesn't already provide NAT for host3, you also have to SNAT
the connection:

iptables -t nat -A POSTROUTING -p tcp -d host3 --dports 22 -j SNAT
--to-source host2_Ip_address

Of course, iptables is Linux specific, so you would need to use whatever
equivalent utility for the host2 operating system.  Using SSH, even with
the double encryption over the internal network, might be the path of
least resistance.  (And you can amuse yourself imagining the look on an
attacker's face if he's been sniffing the traffic on the internal
network and cracks the ssh encryption, only to find another encrypted
stream.)