[kwlug-disc] ssh and port forwarding

[unsolicited]

Robert P. J. Day wrote, On 12/15/2008 2:34 PM:
> On Mon, 15 Dec 2008, Rashkae wrote:
> 
>> 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.)
> 
>   in my case, i really only need the encryption on the first segment,
> from the user to the corporate VPN.  once i'm in, the second
> connection from the host2 gateway to host3 can be insecure.  but it
> doesn't hurt to secure both of them, it's just overkill.

As Rashkae pointed out, his good solution does leave host3 exposed to 
the internet. But, you're VPNing in, so as long as the firewall 
doesn't expose the port you should be OK.

Isn't the simplest solution to pass the initial command argument on 
your invocation?

ssh me at host1 ssh me at host2

Things still run on host2 as you desire. You point out that the 
internal connection need not be encrypted so the 2nd ssh could be 
telnet. [But running telnet anywhere is a 'bad thing'.]