Re: SSH tunneling/port forwarding and stateful packet inspection
From: Jeffrey J. Kosowsky (kosowsky_at_consult.pretender)
Date: Sun, 07 Mar 2004 05:04:31 GMT
firstname.lastname@example.org (Darren Tucker) writes:
> In article <email@example.com>,
> Jeffrey J. Kosowsky <firstname.lastname@example.org> wrote:
> > Also, is there any way to continue to use straight SSH most of the
> > time, but only use the additional 'stunnel' wrapper when it is
> > absolutely necessary?
> ProxyCommand can be a script which behaves differently in different
> environments, see:
Do you know how much extra "overhead" is introduced by running ssh
over ssl instead of just running ssh directly?
> Note that if you're running an SSL-wrapped sshd, it will have to be
> on a different port to the non-wrapped one.
Now this could be a challenge since the only "guaranteed" open port is
Could I instead use something like dyndns so that port 446 gets
forwarded to a different open port on my router (but appears as 446 to
the outgoing firewall)?
So for example when using ssh directly:
ssh -> Port 446 (out) -> myname.dyndns -> Port 22 (in) on my router
While when using ssh over ssl:
ssh -> Port 446 (out) -> Port 446 on my router
> I set stunnel up here to see if it was possible. It is, but it's
> compilicated. The following applies to OpenSSH (it might be possible
> with other SSH software, but I don't know.)
> In this example the client and server are on the same Redhat 9 box, but
> the theory appears sound, so it could also work across systems (and
> proxies!) too. The tools are OpenSSH's ssh/sshd (3.8p1), xinetd (2.3.11),
> stunnel (4.04) and connect (v1.64).
I am assuming that I can get this to work both on my linux Fedora Core
server and my laptop running cygwin (since both use openssh and
However, how would I make this work for putty which I also run on my
> The objective of the exercise looks something like this:
> ssh -(SSHv2)-> stunnel -(SSL)-> connect -(SSL)-> stunnel -(SSHv2)-> sshd.
> In my example, the 2nd stunnel is started by xinetd although it could
> listen itself, and the "connect" process can optionally use a HTTP
> CONNECT or SOCKS proxy too. The target sshd is run in inetd mode, and
> thus talks to stdin/stdout provided by stunnel.