I have a rather unorthodox setup that I'm trying to make work, I've been
bugging the SSH list about this for the past couple of days, and I'm
open to any thoughts on better ways to do this.
Our situation is this: for the next six weeks or so, our office is
stuck using an ISDN modem that does NAT with no port forwarding
capabilities, so we have no straighforward way to enable inbound
connections for people working from home.
My idea for fixing this in a hurry involved running an ssh connection
from one of our internal machines out to our web server, which has a
real Internet connection, and using the ssh port forwarding feature to
enable inbound connections on selected ports. Once I replaced the Red
Hat ssh package with a version that would allow the -R option, this
appeared to work.
But we've run up against a problem or two. The first problem is that we
can only connect to the forwarded port if (a) the inbound process is
running on the web server itself; this in spite of the fact that the ssh
session was started with the -g option; and (b) the inbound process must
address the web server as "localhost"; addressing it as its FQDN or with
its IP address draws a "connection refused". I suspect that these two
problems are related; it appears as though the -g option were being
ignored, or else something in the system at large is preventing
connections to the forwarded port.
The second, and worse, problem is that I can't think up a good way to
monitor the health of the SSH process that's making this possible in the
first place. When I got to the office this morning, the ssh process
appeared to be running as it was when I left it last night, but inbound
connections weren't working. I've since noticed that if the ssh process
is unceremoniously killed (as when the IDSN modem resets), the forwarded
port stays open on the web server, causing subsequent equivalent ssh
sessions to fail when they try to bind to the already-open port; so
enclosing the ssh session command in a "while /bin/true" loop won't work.
As this solution gets messier and messier, I'm starting to think that
there must be a better way to approach this problem, and I'm fishing for
ideas. Sorry for the cross-posting.
-m
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
