SSH tunneling/port forwarding and stateful packet inspection
steve
difficulty understanding how if a person is running an ssh tunnel from
an internal client to an external server doing port forwarding all via
port 443, than how come stateful packet inspection doesn't catch this
and allow it to pass through?
Richard E. Silverman
This is too vague. State the actual problem you are encountering, with
precise configuration, products involved, and symptoms you are observing.
--
Richard Silverman
r...@qoxp.net
steve
> This is too vague. State the actual problem you are encountering, with
> precise configuration, products involved, and symptoms you are observing.
Its not a problem per se but I am curious. I don't think actualy
products involved are an issue. Lets just speak generally when talkimg
about common firewalls.
However, I think I may have answered my own question already when I
was thinking about this earlier today.
The scenario is this - point A - a machine running an ssh clinet that
is tunneling via port 443 to point B - a server running an ssh server
on port 443. Point A - the client is using ghe tunnel to port forward
terminal service traffic. My question was, why doesnt the firewall
pick this up in SPI because it is not really sll traffic. However, in
doing a packet trace, I saw that the header of the packet really is
ssl traffic, but the actual port 3389 (term server) traffic a)
encrypted and b) encapsulated. So as far as teh SPI functionality of
the firewall is concerned, it is SSL traffic.
Does this sound feasible?
Richard E. Silverman
> packet really is ssl traffic, but the actual port 3389 (term server)
> traffic a) encrypted and b) encapsulated. So as far as teh SPI
> functionality of the firewall is concerned, it is SSL traffic.
Your terminology is confused and you want "SSH" here, not "SSL" (these are
two entirely different protocols) -- but I suppose you've got the idea.
All the firewall can see is a TCP connection whose contents are entirely
opaque because they are encrypted. The fact that the connection is being
to forward traffic between two other TCP connections elsewhere is
invisible to the firewall.
--
Richard Silverman
r...@qoxp.net
steve
My terminology is not mixed up. According to my packet trace, because
I have reconfigured SSH to run over port 443 the trace shows it as SSL
traffic. Of course the contents are encrypted. This is my whole
conclusion why the stateful packet inspection capabilities of the
firewall do not blow it going outbound. Because to it, it is just an
SSL packet encapsulating SSH data, which of course is encrypted.
Darren Dunham
> The scenario is this - point A - a machine running an ssh clinet that
> is tunneling via port 443 to point B - a server running an ssh server
> on port 443.
You did this by running the ssh server on port 443, and then ran a ssh
client to explicitly contact it on port 443? Are you doing this to go
through a firewall that doesn't have port 22 open?
> Point A - the client is using ghe tunnel to port forward
> terminal service traffic. My question was, why doesnt the firewall
> pick this up in SPI because it is not really sll traffic. However, in
> doing a packet trace, I saw that the header of the packet really is
> ssl traffic, but the actual port 3389 (term server) traffic a)
> encrypted and b) encapsulated. So as far as teh SPI functionality of
> the firewall is concerned, it is SSL traffic.
It's on port 443. That may be all the firewall is looking at to
consider it SSL traffic. It's still an SSH protocol.
What did you see in the header to determine that it is ssl traffic?
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Darren Tucker
steve <steph...@yahoo.com> wrote:
>
>My terminology is not mixed up. According to my packet trace, because
>I have reconfigured SSH to run over port 443 the trace shows it as SSL
>traffic. Of course the contents are encrypted. This is my whole
>conclusion why the stateful packet inspection capabilities of the
>firewall do not blow it going outbound.
A firewall could easily stop this by looking at the first few bytes sent
by the server, and killing the connection if those bytes are "SSH-"
It works now because most firewalls either don't have the capability to
"peek" into the packets, or don't do it for port 443.
>Because to it, it is just an
>SSL packet encapsulating SSH data, which of course is encrypted.
It's not an SSL packet encapsulating anything. It's just an SSH
connection on port 443. Your packet trace tool just can't tell the
difference.
--
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.
Richard E. Silverman
> My terminology is not mixed up. According to my packet trace, because I
> have reconfigured SSH to run over port 443 the trace shows it as SSL
> traffic.
You are mistaken. Your packet trace identifies the TCP connection as
carrying the SSL protocol simply because the destination port is 443,
which is the well-known port for HTTP over SSL. In other words, your
tracing tool is not inspecting the contents of the connection, merely
labelling it on the basis of the destination port -- which in this case is
misleading because you happen to be running an SSH server on the port
normally used for HTTPS.
> Of course the contents are encrypted. This is my whole conclusion why
> the stateful packet inspection capabilities of the firewall do not blow
> it going outbound. Because to it, it is just an SSL packet encapsulating
> SSH data, which of course is encrypted.
The data are indeed encrypted, but by SSH; there is no SSL connection
anywhere in this scenario. Also, even if it were not encrypted
(e.g. select the "none" cipher for the SSH connection), the port-forwarded
TCP connections would still not be blocked by the firewall, as the
forwarding is happening at an entirely different level, as I pointed out
in my last post.
--
Richard Silverman
r...@qoxp.net
steve
> In article <41e63564.04022...@posting.google.com>,
> steve <steph...@yahoo.com> wrote:
> >
> >My terminology is not mixed up. According to my packet trace, because
> >I have reconfigured SSH to run over port 443 the trace shows it as SSL
> >traffic. Of course the contents are encrypted. This is my whole
> >conclusion why the stateful packet inspection capabilities of the
> >firewall do not blow it going outbound.
>
> A firewall could easily stop this by looking at the first few bytes sent
> by the server, and killing the connection if those bytes are "SSH-"
>
> It works now because most firewalls either don't have the capability to
> "peek" into the packets, or don't do it for port 443.
>
> >Because to it, it is just an
> >SSL packet encapsulating SSH data, which of course is encrypted.
>
> It's not an SSL packet encapsulating anything. It's just an SSH
> connection on port 443. Your packet trace tool just can't tell the
> difference.
Any sniffers (software sniffers) that can see it?
Darren Tucker
steve <steph...@yahoo.com> wrote:
>dtu...@dodgy.net.au (Darren Tucker) wrote in message news:<c1jcoi$tar$1...@gate.dodgy.net.au>...
>> >SSL packet encapsulating SSH data, which of course is encrypted.
>>
>> It's not an SSL packet encapsulating anything. It's just an SSH
>> connection on port 443. Your packet trace tool just can't tell the
>> difference.
>
>Any sniffers (software sniffers) that can see it?
Probably not, and it's probably not distinguishable on a per-packet basis.
In theory a sniffer could observe the SSH protocol startup in the first
packet or two and remember that the particular (src ip, src port, dst ip,
dst port) connection is really SSH.
Alternatively, they could just assume that anything on port 443 is SSL,
which is what they all seem to do.
steve
> > My terminology is not mixed up. According to my packet trace, because I
> > have reconfigured SSH to run over port 443 the trace shows it as SSL
> > traffic.
>
> You are mistaken. Your packet trace identifies the TCP connection as
> carrying the SSL protocol simply because the destination port is 443,
> which is the well-known port for HTTP over SSL. In other words, your
> tracing tool is not inspecting the contents of the connection, merely
> labelling it on the basis of the destination port -- which in this case is
> misleading because you happen to be running an SSH server on the port
> normally used for HTTPS.
I never said it WAS ssl traffic. I said the trace showed it to be ssl
traffic and I know full well it is not. So cut out the condescending
tone already. I also know it is labeling it as such, which brings me
back to my original point AND leads me to pose my next question - are
there any firewalls that can see and block this type of traffic (and
not based on the previous response to "shut down traffic" based on the
packet carrying "anything that says SSH" - this is plain ridiculous).
>
> > Of course the contents are encrypted. This is my whole conclusion why
> > the stateful packet inspection capabilities of the firewall do not blow
> > it going outbound. Because to it, it is just an SSL packet encapsulating
> > SSH data, which of course is encrypted.
>
> The data are indeed encrypted, but by SSH; there is no SSL connection
> anywhere in this scenario. Also, even if it were not encrypted
> (e.g. select the "none" cipher for the SSH connection), the port-forwarded
> TCP connections would still not be blocked by the firewall, as the
> forwarding is happening at an entirely different level, as I pointed out
> in my last post.
I fail to see where you pinted that out. And when talkimg about
"level" do you mean layers? If so, what layer would that be that - I
would hope it would be on another layer.
steve
I am also not buying this whole -argument that the firewalls stateful
pakcet inspection is only looking at the port it is going to. Most
firewalls (even free ones) have SPI that looks into the application
layer of a packet and based on the known patterns of that packet, will
know to allow it to pass or block it. If it didn't than SPI would be
uttelry useless in that a client could easily route any type of
traffic it wanted over known open ports - for example, say a company
is blocking all traffic except outbound port 80 traffic - then by what
you guys are saying is that all one would need to do is simply tell an
application like AIM to use port 80 because all it is looking at is
initiation portion of the packet, in lay terms "oh, its port 80
traffic, let it on through!." But in my understanding of SPI, this
isn't the case - it knows the patterns of what true port 80 traffic
looks like and if someone is trying to pass AIM traffic over port 80,
it sees it and says "no no, you cannot go through even if you are
outbound port 80, you don't fit the pattern"
So, in knowing how SPI really works (in in fact DOES look into a
packet) my question is that if a packet is encrypted, AND it is going
over 443, it knows to pass it beacuse a) it is outbound over 443 (the
firewall rule knws to let it go) and b) since it is encrypted it meets
the criteria of the "pattern" so SPI doesnt need to block it.
IF this is the case, then port 443 is an inherent vulnerability from
many vectors. That is what I am trying to understand. I don't think
either of you understand any more than I do about the engineering
behind how a firewalls SPI works in regards to any port 443 traffic.
In that case, the only way to block outbound 443 would be to shut it
off, and that is not an option.
Darren Dunham
> I am also not buying this whole -argument that the firewalls stateful
> pakcet inspection is only looking at the port it is going to. Most
> firewalls (even free ones) have SPI that looks into the application
> layer of a packet and based on the known patterns of that packet, will
> know to allow it to pass or block it. If it didn't than SPI would be
> uttelry useless in that a client could easily route any type of
> traffic it wanted over known open ports - for example, say a company
> is blocking all traffic except outbound port 80 traffic - then by what
> you guys are saying is that all one would need to do is simply tell an
> application like AIM to use port 80 because all it is looking at is
> initiation portion of the packet, in lay terms "oh, its port 80
> traffic, let it on through!." But in my understanding of SPI, this
> isn't the case - it knows the patterns of what true port 80 traffic
> looks like and if someone is trying to pass AIM traffic over port 80,
> it sees it and says "no no, you cannot go through even if you are
> outbound port 80, you don't fit the pattern"
Exactly. I think you will need to specify a particular product here. I
don't know if such a thing is true "in general" or not.
I do know that my stateful ipfilter firewall at home is doing only tcp
port inspection and not application layer inspection on most things.
The built-in ftp proxy is an exception.
Instead the fact that my firewall also forwards all 80/443 traffic to my
web proxy protects from this abuse. The fake traffic can't transit the
proxy (unless it's further encapsulated into actual valid HTTP traffic).
That said, I am no expert on firewall or proxy setup, and this thread
seems to be deviating from SSH in particular. This seems to be a
question about what SPIs can and cannot do, not what SSH can or cannot
do.
Richard E. Silverman
> I never said it WAS ssl traffic. I said the trace showed it to be ssl
> traffic and I know full well it is not.
You wrote, several times, that your "packet showed it was SSL" traffic.
You never mentioned that you knew it wasn't, and also wrote that the
firewall could not see inside the stream because it was encrypted by SSL,
which is incorrect. All this suggested you thought there was an SSL
connection somewhere in this scenario, so I was making sure you understood
there wasn't.
> So cut out the condescending tone already.
I'm sorry you saw it that way. I was not trying to be condescending; I
was trying to help you. If you'd rather I not bother, I will be more than
happy to drop it.
> I also know it is labeling it as such, which brings me back to my
> original point AND leads me to pose my next question - are there any
> firewalls that can see and block this type of traffic
What kind of traffic, exactly? I'm still not sure what you would like your
putative firewall to do.
If your question is this: "Is there a firewall that can selectively block
port-forwarding channels within an SSH connection based on their
destination sockets?" -- then the answer is of course, no. SSH
connections are encrypted; if a firewall could see inside them, this would
constitute a successful man-in-the-middle attack against SSH.
> (and not based on the previous response to "shut down traffic" based on
> the packet carrying "anything that says SSH" - this is plain
> ridiculous).
It was not ridiculous; Darren made a sincere and helpful attempt to
understand what you were trying to say -- which has been very unclear so
far -- and to make a suggestion. Ridiculing people who are trying to help
you is a good way to get no more help.
> > ... the port-forwarded TCP connections would still not be blocked by
> > the firewall, as the forwarding is happening at an entirely different
> > level, as I pointed out in my last post.
>
> I fail to see where you pinted that out. And when talkimg about
> "level" do you mean layers? If so, what layer would that be that - I
> would hope it would be on another layer.
There is nothing resembling a TCP connection corresponding to the SSH leg
of a port-forwarding -- there is only a channel within the SSH connection,
i.e. an application-layer protocol construct. This is a) invisible due to
encryption, and b) even if were cleartext it would require the firewall to
track the complete state of by the SSH Transport and Connection protocols
in order to even recognize them; this is much more than most firewalls
ever attempt to penetrate into layers above TCP. Furthermore, it could
not selectively block channels even if it could see them and wanted to,
since they do not consist of discrete sets of IP packets the firewall can
drop. It would have to essentially act as a stealth TCP-layer proxy and
hijack/alter the SSH TCP connection in order to do this -- which would
fail because of SSH integrity checking.
In short, this is simply not something which fits the model of a layer-3
forwarding device.
--
Richard Silverman
r...@qoxp.net
steve
> In article <41e63564.04022...@posting.google.com>,
> steve <steph...@yahoo.com> wrote:
> >dtu...@dodgy.net.au (Darren Tucker) wrote in message news:<c1jcoi$tar$1...@gate.dodgy.net.au>...
> >> >Because to [the sniffer], it is just an
> >> >SSL packet encapsulating SSH data, which of course is encrypted.
> >>
> >> It's not an SSL packet encapsulating anything. It's just an SSH
> >> connection on port 443. Your packet trace tool just can't tell the
> >> difference.
> >
> >Any sniffers (software sniffers) that can see it?
>
> Probably not, and it's probably not distinguishable on a per-packet basis.
> In theory a sniffer could observe the SSH protocol startup in the first
> packet or two and remember that the particular (src ip, src port, dst ip,
> dst port) connection is really SSH.
>
> Alternatively, they could just assume that anything on port 443 is SSL,
> which is what they all seem to do.
If that is the case, then as I said in one of my responses to King
Richard - then this is an inherent vulnerability and firewalls are
pretty much useless for security. They are more or less a "control"
mechanism to keep users from doing things.
Richard E. Silverman
> If that is the case, then as I said in one of my responses to King
> Richard - then this is an inherent vulnerability and firewalls are
> pretty much useless for security. They are more or less a "control"
> mechanism to keep users from doing things.
You say this as if it were a surprise. It's not. Firewalls are not
"useless," but they have their limits, as does any particular technique.
In particular, any time you allow two parties an unrestricted channel
(e.g. the ability to form a TCP connection), they can do absolutely
anything they want with it -- including circuventing blocks you have put
in place to prevent communication on other channels. To prevent this, you
would have to shut off direct IP routing at your security border, and only
provide people with application-level proxies for specific protocols. And
you would have to be very careful that your proxies do not allow the
formation of unrestricted channels over themselves (e.g. the HTTP CONNECT
command). Even then, complete control is practically impossible due to
the existence covert or side channels. This is just the reality of how
communication works.
firewall != security
--
Richard Silverman
r...@qoxp.net
Darren Tucker
>not based on the previous response to "shut down traffic" based on the
>packet carrying "anything that says SSH" - this is plain ridiculous).
Assuming you are referring to what I said, that was "A firewall could
easily stop [SSH on port 443] by looking at the first few bytes sent by
the server, and killing the connection if those bytes are "SSH-".
This is true for standards-compliant SSH clients and servers, since the
SSH protocol ([1] section 4.2) specifies that
[quote]
When the connection has been established, both sides MUST send an
identification string of the form "SSH-protoversion-softwareversion
comments", followed by carriage return and newline characters
[/quote]
There's a similar requirement for the SSHv1 protocol.
Now this would not stop modified clients and servers, nor would it stop
someone using extra software at both ends (eg "stunnel") and running
SSH over the top of that. The latter *would* involve SSL.
>And when talkimg about
>"level" do you mean layers? If so, what layer would that be that - I
>would hope it would be on another layer.
OK, here's a recap:
If you run a standard SSH client on port 22, you have:
SSH Protocol -> TCP(22) -> IP -> link layer -> physical layer
That's 5 layers: the standard 4 for TCP/IP and 1 of SSH. No SSL.
If you run a standard SSH client on port 443 (ie just with a "Port 443"
directive or similar), you have the same number of layers:
SSH Protocol -> TCP(443) -> IP -> link -> physical
Also 5 layers. Also no SSL.
If you use SSH to forward on or more TCP ports over that, each will be
carried inside a "channel" inside the SSH protocol (which is, itself
being carried over a single TCP connection to port 443):
TCP forwarding channel -> SSH Protocol -> TCP(443) -> IP -> link -> phys
At the middle of this (ie the "TCP(443)" point, which is what your firewall
sees), you can't tell if there are any TCP forwarding.
Now let's say you're using a HTTP proxy on port 3128 (eg "Proxy Type =
HTTP" in PuTTY) to a SSH server on port 443, then between the client and
the proxy there are 6 layers:
SSH -> HTTP(CONNECT) -> TCP(3128) -> IP -> link -> physical
but between the proxy and the server there are 5 layers:
SSH -> TCP(443) -> IP -> link -> physical
Still no SSL in any of these scenarios.
I'm not going to get into the SPI/Stateful Inspection thing since it's
off topic here.
[1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-17.txt
Jeffrey J. Kosowsky
> steve <steph...@yahoo.com> wrote:
> > I am also not buying this whole -argument that the firewalls stateful
> > pakcet inspection is only looking at the port it is going to. Most
> > firewalls (even free ones) have SPI that looks into the application
> > layer of a packet and based on the known patterns of that packet, will
> > know to allow it to pass or block it. If it didn't than SPI would be
> > uttelry useless in that a client could easily route any type of
> > traffic it wanted over known open ports - for example, say a company
> > is blocking all traffic except outbound port 80 traffic - then by what
> > you guys are saying is that all one would need to do is simply tell an
> > application like AIM to use port 80 because all it is looking at is
> > initiation portion of the packet, in lay terms "oh, its port 80
> > traffic, let it on through!." But in my understanding of SPI, this
> > isn't the case - it knows the patterns of what true port 80 traffic
> > looks like and if someone is trying to pass AIM traffic over port 80,
> > it sees it and says "no no, you cannot go through even if you are
> > outbound port 80, you don't fit the pattern"
I believe I have just experienced an example of a firewall with SPI that
blocks my ability to set up an SSH connection via 443.
As a consultant, I typically need to access my email from various
client sites where I don't have a local account.
My solution around firewalls has always been to run SSH over port 443
since this port is almost always open.
I have not had any problems with this until recently, when I
encountered a client where I was unable to set up such an SSH
connection. They are using a "Raptor" firewall that apparantly as its
default does SPI which can tell that I am passing SSH rather than SSL
traffic (I don't know this firsthand, it is just what their junior
network guy said).
- Assuming that is true, what alternatives do I have to access my
network from inside their firewall?
(note: the company has nothing against me doing it, they just don't
want to change their firewall)
- One answer I heard is to run SSH over SSL using something like
'stunnel'. However, I could use some pointers on how to do
this.
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?
- Has anyone else encountered (and solved) similar issues?
Jeff
Darren Tucker
Jeffrey J. Kosowsky <koso...@consult.pretender> wrote:
[snip]
>- One answer I heard is to run SSH over SSL using something like
> 'stunnel'. However, I could use some pointers on how to do
> this.
See below.
> 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:
http://www.taiyo.co.jp/~gotoh/ssh/connect.html#sec13
Note that if you're running an SSL-wrapped sshd, it will have to be
on a different port to the non-wrapped one.
>- Has anyone else encountered (and solved) similar issues?
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).
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.
First, I added a "sshs" service (for want of a better name) to
/etc/services, then configured xinetd to listen on it:
# cat /etc/xinetd.d/sshs
service sshs
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/stunnel
server_args = /etc/stunnel/sshs-server.conf
disable = no
}
Next I made some certs for this service:
# cd /usr/share/ssl/certs
# make sshs-client.pem
# make sshs-server.pem
(I later had to make this one world-readable so stunnel could read it).
I copied the "CERTIFICATE" parts of those files (ie the public keys)
to the equivalent files in /etc/stunnel.
I then created the stunnel config files:
# cd /etc/stunnel
# cat sshs-server.conf
cert = /usr/share/ssl/certs/sshs-server.pem
CAfile = /etc/stunnel/sshs-client.pem
exec = /usr/local/sbin/sshd
execargs = /usr/local/sbin/sshd -i
# cat sshs-client.conf
cert = /usr/share/ssl/certs/sshs-server.pem
CAfile = /etc/stunnel/sshs-client.pem
foreground = yes
client = yes
exec = /usr/local/bin/connect
execargs = connect localhost sshs
Then finally used ssh's ProxyCommand option to use stunnel to connect:
$ ssh -o "ProxyCommand stunnel /etc/stunnel/sshs-client.conf" localhost
2004.03.05 13:29:51 LOG5[13727:16384]: stunnel 4.04 on i386-redhat-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7a Feb 19 2003
2004.03.05 13:29:51 LOG4[13727:16384]: Wrong permissions on /usr/share/ssl/certs/sshs-server.pem
[login messages]
$ logout
Good luck!
Jeffrey J. Kosowsky
> In article <m2vflk5...@consult.pretender>,
> Jeffrey J. Kosowsky <koso...@consult.pretender> wrote:
> [snip]
> > 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:
> http://www.taiyo.co.jp/~gotoh/ssh/connect.html#sec13
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
446.
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
openssl).
However, how would I make this work for putty which I also run on my
laptop?
Darren Tucker
Jeffrey J. Kosowsky <koso...@consult.pretender> wrote:
>Do you know how much extra "overhead" is introduced by running ssh
>over ssl instead of just running ssh directly?
Well, for one thing you'll double the CPU usage. In most cases CPU will
not be your bottleneck, though.
>> 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
>446.
You mean 443 (ie https)?
>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
Not sure as I'm not familiar the the forwarding service you're referring
to. Sounds reasonable, though.
>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
>openssl).
Probably yes.
>However, how would I make this work for putty which I also run on my
>laptop?
I don't think PuTTY has an equivalent of ProxyCommand, but you could use
stunnel's "accept" option and then point PuTTY at localhost.