anyway to ssh tunnel through 2 firewalls ?
James
is there a way to tunnel through 2 firewalls with ssh. The setup lis
as follow:
client -> fw1 -> fw2 ->server
i can ssh from the client into fw1 then into fw2 and finally into the
server. But what i really need is to be able to run a client app that
talk to a daemon process on the server directly.
-thanks
James
Kyler Laird
>client -> fw1 -> fw2 ->server
>i can ssh from the client into fw1 then into fw2 and finally into the
>server. But what i really need is to be able to run a client app that
>talk to a daemon process on the server directly.
Yeah, I've done this. It's not pretty, but you can
certainly chain tunnels. Lessee if I get this right...
client % ssh -L 1234:localhost:1234 fw1 \
"ssh -L 1234:localhost:1234 fw2 \
\"ssh -L 1234:localhost:1234 server\""
(Client app talks to localhost:1234.)
If you really trust the connections between client and
fw1 and between fw2 and server, you *could* simplify
this down to a single tunnel.
client % ssh fw1 "ssh -L 1234:server:1234 fw2"
(Client app talks to fw1:1234.)
--kyler
Darren Tucker
Kyler Laird <Ky...@news.Lairds.org> wrote:
>James <j...@excite.com> writes:
>
>>client -> fw1 -> fw2 ->server
>
>>i can ssh from the client into fw1 then into fw2 and finally into the
>>server. But what i really need is to be able to run a client app that
>>talk to a daemon process on the server directly.
>
>Yeah, I've done this. It's not pretty, but you can
>certainly chain tunnels. Lessee if I get this right...
[snip]
There's a different way to do this. Grab and install "connect"
(http://www.taiyo.co.jp/~gotoh/ssh/connect.html) on fw1 and fw2.
On "client", create a $HOME/.ssh/config like the following:
Host fw2
ProxyCommand ssh fw1 connect fw2 22
Host server
ProxyCommand ssh fw2 connect server 22
This has advantages and disadvantages. You can "stack" the connections
pretty much transparently. You don't have to worry about multiple
sessions not working because of busy ports. You end up triple-
encrypting the traffic at the point "client->fw1" though.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Kyler Laird
>>>client -> fw1 -> fw2 ->server
>There's a different way to do this. Grab and install "connect"
>(http://www.taiyo.co.jp/~gotoh/ssh/connect.html) on fw1 and fw2.
Installing new software on firewalls needs to result
in some clear benefits for me.
>On "client", create a $HOME/.ssh/config like the following:
>Host fw2
> ProxyCommand ssh fw1 connect fw2 22
>Host server
> ProxyCommand ssh fw2 connect server 22
O.k., now what command do you issue on "client"? I
want to track down exactly what you're recommending.
>This has advantages and disadvantages. You can "stack" the connections
>pretty much transparently. You don't have to worry about multiple
>sessions not working because of busy ports.
I want to see these advantages. This looks a lot like
some things I've been kludging together for years (far
before ProxyCommand). I'd like to take advantage of a
cleaner way to do things, but I'm not seeing where the
advantage is in this case.
Namely, I don't see how this is any more transparent
than just initiating a tunnel chain from "client" using
standard ssh commands, and I don't see why "multiple
sessions" would break "because of busy ports."
>You end up triple-
>encrypting the traffic at the point "client->fw1" though.
Ug.
--kyler
arvidjaar
"Kyler Laird" <Ky...@news.Lairds.org> wrote in message
news:f1rhj-...@news.lairds.org...
> dtu...@dodgy.net.au (Darren Tucker) writes:
>
> >>>client -> fw1 -> fw2 ->server
>
> >There's a different way to do this. Grab and install "connect"
> >(http://www.taiyo.co.jp/~gotoh/ssh/connect.html) on fw1 and fw2.
>
>
> I want to see these advantages. This looks a lot like
> some things I've been kludging together for years (far
> before ProxyCommand). I'd like to take advantage of a
> cleaner way to do things, but I'm not seeing where the
> advantage is in this case.
>
If fw1 and fw2 run sshd and you have user account there - there is no
advantage.
connect comes useful when firewall does not speak ssh or you cannot access
it. It supports SOCKS/HTTPS so you can tunnel (OpenSSH) connection through
normal SOCKS/HTTP proxy. But in your case you can make connection only from
client to fw2 via fw1. You still need either prot forwarding on fw2 setup in
advance or some agent on fw2 that forward connection on demand.
=arvi=
Darren Tucker
Kyler Laird <Ky...@news.Lairds.org> wrote:
>dtu...@dodgy.net.au (Darren Tucker) writes:
>>On "client", create a $HOME/.ssh/config like the following:
>>Host fw2
>> ProxyCommand ssh fw1 connect fw2 22
>>Host server
>> ProxyCommand ssh fw2 connect server 22
>
>O.k., now what command do you issue on "client"? I
>want to track down exactly what you're recommending.
"ssh server"
>>This has advantages and disadvantages. You can "stack" the connections
>>pretty much transparently. You don't have to worry about multiple
>>sessions not working because of busy ports.
>
>I want to see these advantages. This looks a lot like
>some things I've been kludging together for years (far
>before ProxyCommand). I'd like to take advantage of a
>cleaner way to do things, but I'm not seeing where the
>advantage is in this case.
With the chain of port-forwards, anyone with access to "client" or any
of the intermediate hops can use your tunnel for access they would not
normally have.
With what I'm describing there's no intermediate listening ports, it's
all stdin/stdout.
>Namely, I don't see how this is any more transparent
>than just initiating a tunnel chain from "client" using
>standard ssh commands, and I don't see why "multiple
>sessions" would break "because of busy ports."
I didn't state that very well. Here's what I was getting at:
Try having many people use this scheme on the same set of hosts: you'll
have problems unless you're very strict with the port allocation (which
means everybody must maintain their own config files). You may end up
connecting to the wrong machine because someone started their tunnel
first on the port you intended to use, or have a connection you're
using torn down because the originator disconnected it.
It won't work at all if the port is busied out by another application.
>>You end up triple-
>>encrypting the traffic at the point "client->fw1" though.
>Ug.
Yeah, that's a downside. For me the advantages outweigh the extra
overhead.
It'd be nice if you could use no encryption for the intermediate hops
and only encrypt the end-to-end session and ssh could do the
stdin/stdout->tcp forward request without "connect". That'd cut the
overhead way down.