Permanent or automated SSH tunnel--possible?

[Galen Tackett]

We have three networks which for simplicity I'll call NetA, NetB, and NetC. There are router connections between NetA and NetB and between NetB and NetC, but not directly from NetA to NetC. On each of these is a host (HostA, HostB, HostC) running TCP/IP Services V5.4 or later, with SSH enable.

I've just figured out how to use SSH to tunnel Telnet between HostA and HostC through HostB.

Every time I want to do this, though, I have to first log in to HostB using a command like
(1) HostA$ ssh HostB -"L" 20023:HostC:23
to establish the tunnel. Then I can do
(2) HostA$ ssh localhost 20023
to log in to HostC from HostA.

Ideally I'd like for anyone on NetA to be able to telnet to HostC via an ssh tunnel through HostB. This is a small user community, only about 5-10 people, each with his own Alpha VMS workstation on NetA; both HostB and HostC are rx1620's with lots of extra resources, so I'm not terribly concerned about load on either of these.

Is there some way a more permanent tunnel can be established, or that (1) can be automated so the user doesn't have to issue this command manually every time he logs in? Having to enter a password for HostB complicates this.

Another issue that's peripherally related is how to get the best performance out of limited bandwidth. The links to NetB from both NetA and NetC run over quite slow connections, on the order of 56Kb/sec each. This of course makes for some noticeable pauses in I/O when you have to traverse both links to get from NetA to NetC.

The best solution, of course, would be a direct connection between NetA and NetC, or minus that possibility, a much higher speed over the existing links. Doing either involves politics between us and our USGov customers that is so far removed from me that the folks involved have no idea of the existence of such a lowly and rare creature as our single project's VMS system manager.

I'd like to hear any help or commentary on either of these areas.

Thanks,

Galen

[Robert Gezelter · Accepted solution]

Galen,

I am in the middle of working on something, but have you considered using stunnel directly?

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

You're establishing a gateway to get through to your target network. (Are these all private-address LANs?)

A reasonable firewall can provide VPN and sometimes VLAN services such as this, as can configurations built on various of the firewalls. (OpenVMS trails other OS options here, with limited VPN integration and no in-built firewall.) For some of the other out-board options here, see m0n0wall, smoothwall, dd-wrt and various mid-grade firewalls.

See what firewalls you have installed here (as most folks have firewalls), and see if the combination already in use can solve this matter for you.

As for speed, if you can't up the pipeline, you have to compress the data (if feasible) or reduce the load.

[Steven Schweda]

> [...] here are router connections between
> NetA and NetB and between NetB and NetC,
> but not directly from NetA to NetC. [...]

I assume that I'm missing something obvious,
but why not add a route to NetC (gateway =
RouterBC) on the systems on NetA? If the
systems on NetA can talk to systems on NetB,
then they should be able to talk to RouterBC,
and if they only knew that that was how to
get to NetC, then they should be able to do
so with no extra fooling around.

So, what am I missing?

[Galen Tackett]

Bob said,
> have you considered using stunnel directly?

Hoff said,
> See what firewalls you have installed here (as most folks have firewalls),
> and see if the combination already in use can solve this matter for you.


Steven said,
> I assume that I'm missing something obvious, but why not add
> a route to NetC (gateway = RouterBC) on the systems on NetA?

The govt. actually requires us to have ssh on our IP hosts. stunnel might be workable though open source means a harder sell. (Not needed for ssh since they require us to have it.) I also need to read up on stunnel, since I know nothing about it right now.

It's all bureaucracy and money--remember who the customer is.

If you aren't allergic to bureaucracy and want a more complete picture, read on. Otherwise you may wish to stop reading here. :-)

All the network infrastructure is govt. owned, though we operate the portion within our own facility.

Govt. security has to approve any network connections we make, even in our own facility; multipe customer security offices are probably involved; lots of paperwork, preceded by lots of oral discussion, is _definitely_ involved. Even getting them interested in listening isn't always easy.

New approvals would be required whether we used an existing firewall or added a routing entry on HostB. Adding a _new_ firewall would be even more difficult since customer money would also be involved.

Host B is about 20 miles away in a govt. facility. Hosts A and C are in our facility. Though we administer all three, we have considerably less flexibility with B.

[Steven Schweda]

> [...] we have considerably less flexibility
> with B.

So, what's the problem with "TCPIP route add"
on NetA hosts?

> So, what am I missing?

[Galen Tackett]

> So, what's the problem with "TCPIP route add"
on NetA hosts?

I've tried just this but forgot to mention it.

With such a routing entry on NetA, traceroutes from NetA to NetC look like a firewall is blocking them somewhere in the govt. infrastructure in between, but I don't know for certain. That part of it is just a big cloud to me, unfortunately.

[Steven Schweda]

> I've tried just this but forgot to mention it.

Lacking any details, I might guess that you'd
also need to do something similar on the NetC
hosts, adding a route through RouterAB to
NetA. That is, it might help if the guys at
the far end knew how to get a reply back to
the guys at the near end, too.

[Richard Whalen]

You could eliminate the need to enter a password for HostB by setting up public key authentication between HostA and HostB. This doesn't automate or make permanent the tunnel, but does make setting it up a bit easier.

[Galen Tackett]

I now have stunnel working for telnet connections between A and C by way of B.

I tried out the option to use rle compression and for normal interactive use it seemed faster.

I wanted to try zlib compression too but ssl has to be rebuilt to support zlib. I'm going to look into that. Any tips will be welcome.

Thanks, Bob, for mentioning stunnel.

In our environment we really don't need all the strong encryption that you get with stunnel (by way of ssl), but at least it solves the problem of getting from A to C.

Now, since ftp won't work through stunnel I'm going to be looking for a way to do ftp's as well.

Thanks for everyone's input. This topic is almost to the point where I can close it, at which time I will assign points too.