SSH using TCP proxies?

[Thomas A. Williams]

Here's the situation:

Currently we've got some DCL scripts that access remote nodes via DECnet using proxies.

The auditors have told us we must do away with DECnet, and we must migrate to ssh for all our network ops.

My boss REALLY doesn't want to deal with public key authentication (he thinks it's a management nightmare which I tend to agree with) and host based authentication is not secure enough (auditors again).

Is there any way at all to use TCP proxies with SSH? That would be a great solution for us.

If not, can anyone think of a way to mimic what is done with proxies on SSH without having to use hostbased or public key auth? Some trick I'm not finding in my Google searches?

Thanks in advance.

[Wim Van den Wyngaert]

About SSH :

1) consumes a lot of cpu (e.g. file transfers)
2) slows down the opening of a tcp connection a lot
3) on old architecture : loss of thruput (E.G. RTP / SCP)
4) is only as secure as your VMS system. If people have privs, they can steal the keys
5) to be really secure, you need to tunnel all TCP traffic such as db access and interapplication communication
6) Sad but contains a lot of bugs (and requires the latest version so not on 7.3)

But what are you exactly asking ? To have trusted hosts without exchanging keys ?

Wim

[Steven Schweda]

My SSH experience is limited to public key
authorization, and I don't have any clever
ideas on alternatives.

Have you considered a more exotic solution,
like tunneling the DECnet traffic through
TCP/IP, and perhaps using something like
"stunnel" to keep the TCP/IP traffic from
prying eyes?

Although I don't do it, I gather that this
sort of scheme makes it possible nowadays to
retain DECnet functionality while not telling
the network people that you're actually still
using it.

http://h71000.www7.hp.com/network/migration.html

[Thomas A. Williams]

1) The bottom line question is if we can do remote passwordless access without using public key or host based authentication. Similar to DECnet and TCP proxies. Or even if there's a way to send an encrypted password to the remote host in an ssh command? I don't think that's possible, however.

Unfortunately, "hiding" our DECnet operations through a tunnel would be out of the question - this is production hardware which is HIGHLY scrutinized by auditors. If we were to try to slip something like that past them, it would mean getting canned.

Thanks for the insight, keep it coming.

[Steven Schweda]

> "hiding" our DECnet operations through a
> tunnel would be out of the question [...]

So, tell them about the tunnel.

What's the reason to stop using DECnet?
(That is, what's the auditors' reason?)

If only TCP/IP traffic appears on the
network, and if it's encrypted as it goes,
then what's left about which to complain?

On the other hand, are public keys really
much harder to handle than setting up the
DECnet proxies was?

Also, as of TCPIP V5.4 - ECO 5 on VMS V7.3-2,
SSH has some behavioral quirks which might
cause trouble in non-interactive use.

[Jan van den Ende]

Thomas,

I know it is asking a lot, and I (we) failed in the attempt, but I would love anybody else to succeed, and that might as well be you.

Have your auditors _EXPLAIN_ what they have against DECnet, and let them _SHOW_ you the relative advantages of IP.
So they want encription?
Have them EXPLAIN why DECnet-over-IP stunnel is not acceptable while SSH is.

By all means, let them be assisted by technical people "from the other side".

Hard to believe, but the ultimate answer _WE_ got is, that the network managers are not able to UNDERSTAND what DECnet is doing, and "therefore, cannot guarantee that it is secure". (which to us all the more proves that it is, but THEY control the settings).

Wishing you better luck, and IF you succeed, report back so we can use you as a referent...

oh well...

Proost.

Have one on me.

jpe

[Thomas A. Williams]

Excellent responses.

1) What are the SSH quirks as of ECO5?


2) Is DECnet over IP able to be encrypted?

[Steven Schweda]

> 1)

The TCPIP ECO 5 release notes may be the
authoratative source. The one which annoys
me is (as the notes say):

o After you execute an SSH remote command, you may need to
press the Enter key to get back to the DCL prompt.

I notice this only interactively, but I fear
that this sort of thing might cause a command
procedure to hang. Actual testing might tell
more than my fearfulness.

> 2)

I'm assuming that there's an "stunnel" for
VMS, and that the DECnet-Plus stuff can be
persuaded to use it. I seem to recall this
being discussed on comp.os.vms, but I know
nothing.

[Wim Van den Wyngaert]

I think it must be possible but can't test it because I have a version much too low.

http://h71000.www7.hp.com/openvms/products/ssh/ssh.pdf

Host-based authentication. This method allows you to avoid specifying any secret information about
the SSH client. Host-based authentication method trusts the relationships between hosts and does not
require you to prove your identity.

Wim

[Thomas A. Williams]

Like I said, host based auth is not an option. The reason for this is: (I've tested this)

The entire node is allowed access to the entire other node.

We need to only allow a particular user access to a specific user account on the remote node. Which of course, public key auth is supposed to be for. Which I'm trying to avoid if at all possible.


Thanks for the suggestions, though.

[Thomas A. Williams]

my boss just stepped in to my cube, and I mentioned this thread. He's interested in reading it.

I also mentioned the possibility of tunneling DECnet with encryption. He said HP told him that was not possible.

Does anyone have any links to more information on this "stunnel". If encrypted DECnet tunneling were possible we might be able to talk the auditors into allowing it.

Thanks.

[Thomas A. Williams]

oh - I just found the info on stunnel. Unfortunately it's freeware which implies no support by HP. Therefore we can't use it.

Damn.

[Steven Schweda]

Potentially trustworthy:

http://h71000.www7.hp.com/opensource/opensource.html#stunnel

Never having used either DECnet-over-IP or
stunnel, I can't say if they can work together,
but it all sounds plausible. (I'm gullible.)

[Jan van den Ende]

Thomas,


I also mentioned the possibility of tunneling DECnet with encryption. He said HP told him that was not possible.


This might still not be definitive.
_WHO_ in HP said so?
If it was VMS Engeneering, that is pretty authorative, but if it was anyone in Marketing or Sales, it means less than the echo of the words that said so.

Hello, Engeneering, anybody listening in and prepared to give the ACTUAL status?
TIA.

Proost.

Have one on me.

jpe

[Thomas A. Williams]

yes, and just to add: It would be very nice if tunneling DECnet over IP _WITH_ encryption was supported, and not freeware. I know, I'm probably wishing for more than is possible. But I can dream....

[Wim Van den Wyngaert]

Could you test again. Read page 30 of my link.


Edit the systemwide trusted hosts file, TCPIP$SSH_DEVICE:[TCPIP$SSH]SHOSTS.EQUIV, to add the fully qualified name of every SSH client host that will communicate with the server. You can also enter a specific user name to limit access to that user.
<\q>

Wim

[Thomas A. Williams]

Wim, regarding this snip of page 30:

========================
2. Edit the systemwide trusted hosts file, TCPIP$SSH_DEVICE:[TCPIP$SSH]SHOSTS.EQUIV, to add the
fully qualified name of every SSH client host that will communicate with the server. You can also enter a
specific user name to limit access to that user. For example:

MYHOST.MYLAB.COM

or

MYHOST.MYLAB.COM smith

If the IgnoreRhosts parameter is set to no as in step 1, you can also add the client host and optional user
names to the file SYS$LOGIN:SHOSTS. for a specific user.
========================

I agree that you can limit access to the remote user smith coming in from MYHOST, but doesn't smith have access to ALL accounts on the local host?

[Ian Miller.]

I noticed in the stunnel web site it says that any protocol using TCP can be tunnelled providing it does not use out of bound data.
I wonder if DECnet NSP or OSI TP4 use out of bound data.