[rescue] how to transparently forward SSH to an internalbox

Steve Sandau rescue at sunhelp.org
Sun Jan 6 14:42:00 CST 2002


George Adkins wrote:
> 
> > If you're going to do this on the firewall, *and* write a wrapper on the
> > client side, it seems that the easiest thing would be just to provide
> > some sort of internal-hostname:ssh-port mapping file on the client.
> No.  how are you supposed to connect to a client on _my_ network via this
> method if I haven't sent you a custom client?  What happens when the mappings
> on the destination network change?
> The client side script needs to be generic.
>
Well, you do *have* to provide some custom client software somewhere.
You just don't want that to have to contain the actual port mappings
then, right? In that case, the client script could just contact the
firewall (really with any of several protocols, including DNS as Greg
suggested) to get the appropriate mapping.

So, by "custom" you just mean something that has hardcoded info that
might need updating, right? Ideally, if we developed something like
this, I could use the special client to connect to something on your
network, my network, or on the network of anyone else who has this set
up the same way. That would be kinda neat.

I am always in favor of using existing tools/protocols to do odd things.
There are some advantages to that, too. Can you run something like rcp
over ssh from a script? tftp to retrieve info or the hostname:port data?
ftp?

> > run a script on the client (call it pssh for private ssh maybe). It
> > takes the same arguments as ssh, but it looks up the hostname you give
> > it in a table on the client, and calls ssh with the appropriate port
> > number so you connect to the firewall running NAT with the right port
> > for the internal host you had in mind.
> Yes, that's exactly what I've been saying for three days.
> what I'm trying to work out is what the best method for that client to
> request that port information from the proxy host...
> 
> > All you have to update on the client is one "hosts" file with internal
> > machine names and their correct ports. This may not fit you purposes,
> > George, but since we *have* to do *some* kind of client modification,
> > why not take the easy way and not have to use anything too odd?
> because we _don't_ have to make custom clients.  we can have a generic client
> script which will allow _anyone_ running it to be able to ssh through to a
> private address machine transparently, without any further preparation than
> dropping a script into their home directory and having an account on the
> target machine.

So the question then is how to get the info to the
written-for-this-purpose client that doesn't have any specific
information about the ports used by the firewall. If I were doing this
now, I'd probably go with a DNS TXT record as Greg suggested. Already in
place, clean, and I already run DNS on my firewall. I'd have the client
resolve the target IP, run nslookup or dig with that target machine as
the server and request the TXT record for that box. Then parse that, use
the port number in the info, and ssh away...
> 
> Yes, it requires a little more effort in the design phase, but once it's in
> place, it's fire-and-forget.  if the proxy-ssh part is written right, you
> might even be able to get it to parse the ipnat.conf on it's own, or maybe
> write it to look at it's own conf file and then build the redirect rules and
> load them into ipnat when it comes up

-- 
Steve Sandau
ssandau at bath.tmac.com



More information about the rescue mailing list