topic Re: Using SSH on OpenVMS V7.3-2 & V8.2 in Operating System - OpenVMS

Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Thu, 12 Oct 2006 12:18:42 GMT

I'm trying to implement SSH on a two node test cluster with a 7.3-2 and a 8.2 node. From here I plan to implement on all our clusters. From what I can see it seems like a big task to administer all those private & public keys. Is there another more generic way to implement SSH/SCP/SFTP and still reap the benefits of encryption?

Also having a problem with a simple test using SSH. From my 8.2 node to my 7.3-2 box I can execute the following command with success:

$ SSH <7.3-2-HOST> SHOW SYSTEM

However the same command from my 7.3-2 node to my 8.2 box returns the following:

Disconnected; connection lost (Connection closed.).

Is there something basic that I'm missing. I have also reconfigured SSH Server and Client on each box with new private and public keys and still get the same message. Any ideas on what's causing this?

Thanks in advance.

-Manny

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Steven Schweda — Thu, 12 Oct 2006 13:04:58 GMT

I use the public key scheme, largely because
it was my only option for my first SSH
experience (involving connection to a host
which I don't administer).

There exists also a "hostbased" scheme for
authentication which might be easier if
you're in charge of both ends. Luckily,
that's about all I know about it. I assume
that there's more in the docs.

> Disconnected; connection lost (Connection closed.).

I haven't seen that one. Perhaps "ssh -v
..." would tell you more.

There should be no particular problem going
from a V7.3-2 system to a V8.2 system.
What're your TCPIP and SSH versions? Around
here:

alp $ ssh "-V"
alp$dka0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (
V5.5) 3.2.0 on COMPAQ Professional Workstation - VMS V7.3-2

alp $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2

alp $ ssh alp2 "tcpip show version"
Authentication successful.

HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.2

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Andreas Vollmer — Fri, 13 Oct 2006 06:24:18 GMT

Hello Manny,

Please verify the config files on both nodes - especial the section AUTHENTICATION.
The config file is located in TCPIP$SSH_DEVICE:[TCPIP$SSH.ssh2] and is called SSH2_CONFIG. & SSHD2_CONFIG.
The authentication type is here defined.
tcpip sho ver

HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1
on a Digital Personal WorkStation running OpenVMS V8.2

Extract out of the SSH2_CONFIG. file.
...
## Authentication
## hostbased, publickey, and password are allowed by default
## (least interactive method should be usually attempted first)

# AllowedAuthentications publickey, keyboard-interactive, passwoâ ¦
AllowedAuthentications hostbased, publickey, password
...

Be aware that SSH on OpenVMS V7.3-2 with TCPIP ECO 5 was updated and got a new config files SSH2_CONFIG. & SSHD2_CONFIG.
These are NOT backwards compatible. Please read the release notes.

$> ssh "-V"
$1$dga100:[sys2.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS
(V5.5) 3.2.0 on COMPAQ AlphaServer DS20E 666 MHz - VMS V7.3-2

$> tcpip sho ver

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 5
on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V7.3-2

$>

I hope these hints are helpfull.
BR
Andreas

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Fri, 13 Oct 2006 13:23:32 GMT

As I mentioned my problem occurs only when I execute the ssh command 'ssh show system' on the 7.3-2 box. Even after re-generating new keys for the servers on each node (now I get that annoying warning about how my host identification has changed).

I have edited the server (sshd2_config.) and client (ssh2_config.) files to include 'AllowedAuthentications hostbased, publickey, password'. I also have copied each nodes public key files into each of the 'hostkeys' directory (used 'key_22_.pub' naming convention). When that didn't work I deleted them. Problem remains.

Personally I would like it if I didn't have to deal with public/private key administration. Is 'port forwarding' a popular option?

As you suggested, I re-ran the command in verbose mode. I have an attachement that will display what the output was during my test.

Here is the version information from each node:

$ ssh "-V"
$1$dga995:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS
(V1.0) 3.2.0 on hp AlphaServer GS1280 7/1300 - VMS V8.2

$ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.5
on an hp AlphaServer GS1280 7/1300 running OpenVMS V8.2

$ ssh "-V"
$1$dga994:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS
(V5.5) 3.2.0 on hp AlphaServer GS1280 7/1300 - VMS V7.3-2

$ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a hp AlphaServer GS1280 7/1300 running OpenVMS V7.3-2

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Steven Schweda — Fri, 13 Oct 2006 13:36:39 GMT

> I have an attachement that will display
> what the output was during my test.

It won't (easily) on my VMS system. Can you
supply a plain-text edition (.txt) instead
of a Microsoft Word mess?

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Fri, 13 Oct 2006 13:59:33 GMT

Here's the text file you requested.

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Steven Schweda — Fri, 13 Oct 2006 14:49:57 GMT

Ok. I can read that.

I gather that you're trying to use
"hostbased" authentication?

> debug: Ssh2AuthHostBasedClient/AUTHC-HOSTBASED.C:721: Server rejected the signature.

That looks bad.

> debug: SshConfig/SSHCONFIG.C:3240: Unable to open ssh2/identification

and you're not set up for public key
authentication.

It might be useful to compare these data with
what you get going in the other (successful)
direction.

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Fri, 13 Oct 2006 16:26:40 GMT

The 'server rejected signature' appears on the output of the successful execution as well.

I've included an attachment that shows the full output.

Below you'll see the output from both (failed and success) starting from the line that reads 'Authentication successful.':

----- failed -----

Authentication successful.
debug: Ssh2Common/SSHCOMMON.C:857: num_channels now 1
debug: Ssh2Common/SSHCOMMON.C:185: DISCONNECT received: Connection closed.
debug: Ssh2/SSH2.C:336: locally_generated = TRUE
Disconnected; connection lost (Connection closed.).
debug: Ssh2Client/SSHCLIENT.C:1684: Destroying client.
debug: SshConfig/SSHCONFIG.C:2788: Freeing pki. (host_pki != NULL, user_pki = NULL)
debug: SshConnection/SSHCONN.C:2342: Destroying SshConn object.
debug: Ssh2Common/SSHCOMMON.C:824: num_channels now 0
debug: Got session close with exit_status=0
debug: destroying client struct...

debug: openvms_emulation_server/OPENVMS_EMULATION_SERVER.C:1110: forcexChildProcess: input pid == 0, no forcex tried.
debug: Ssh2Client/SSHCLIENT.C:1752: Destroying client completed.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:106: Destroying authentication method array.
debug: SshAppCommon/SSHAPPCOMMON.C:335: Freeing global SshRegex context.
debug: SshConfig/SSHCONFIG.C:2788: Freeing pki. (host_pki = NULL, user_pki = NULL)

----- success -----

Authentication successful.
debug: Ssh2Common/SSHCOMMON.C:856: num_channels now 1
OpenVMS V7.3-2 on node xxxxxx 13-OCT-2006 12:26:42.40 Uptime 6 18:05:50
Pid Process Name State Pri I/O CPU Page flts Pages
20800401 SWAPPER HIB 16 0 0 00:00:07.53 0 0
20800407 CLUSTER_SERVER HIB 13 13 0 00:00:00.00 63 78
20800408 SHADOW_SERVER HIB 6 7 0 00:00:00.00 63 84
20800409 CONFIGURE HIB 10 30 0 00:00:00.00 43 21
2080040A USB$UCM_SERVER HIB 6 144 0 00:00:00.03 163 220

. . .

208004C2 _TNA6: LEF 9 4265 0 00:00:00.62 3781 78
208004CA TCPIP$SS_BG5951 CUR 0 9 667 0 00:00:00.09 627 654 N
208004CB _FTA14: CUR 1 7 111 0 00:00:00.01 168 184 N

debug: Ssh2ChannelSession/SSHCHSESSION.C:2375: received exit status : 0
debug: Ssh2Common/SSHCOMMON.C:823: num_channels now 0
debug: Got session close with exit_status=0
debug: destroying client struct...
debug: Ssh2Client/SSHCLIENT.C:1672: Destroying client.
debug: SshConfig/SSHCONFIG.C:2476: Freeing pki. (host_pki != NULL, user_pki = NULL)
debug: SshConnection/SSHCONN.C:2244: Destroying SshConn object.

debug: Ssh2Client/SSHCLIENT.C:1740: Destroying client completed.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:104: Destroying authentication method array.
debug: SshAppCommon/SSHAPPCOMMON.C:320: Freeing global SshRegex context.
debug: SshConfig/SSHCONFIG.C:2476: Freeing pki. (host_pki = NULL, user_pki = NULL)

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Steven Schweda — Fri, 13 Oct 2006 16:48:23 GMT

Hmmm. I'm probably about as mystified as you.

> debug: Ssh2Common/SSHCOMMON.C:185: DISCONNECT received: Connection closed.

It sounds as if something bad happens after
you've been allowed in, but before you get a
DCL prompt. Any chance that there's
something awful in SYS$MANAGER:SYLOGIN.COM
and/or SYS$LOGIN:LOGIN.COM?

Between "num_channels now 1" and the
*LOGIN.COMs, mine discusses "X11 forwarding"
a little. Do you do any odd SET DISPLAY
stuff anywhere? (Is DECwindows installed?)
Any change with "ssh -x"?

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Tue, 17 Oct 2006 15:46:27 GMT

Looks like something bad is happening. I checked both accounting records and the SSH run logs.

I found the following error in accounting:

%SHOW-F-WRITEERR, error writing !AS

I found the following error in the run log:

Received signal 10, SIGBUS: invalid access to memory objects.
%TCPIP-F-SSH_FATAL, non-specific fatal error condition

I checked SYLOGIN.COM and LOGIN.COM. There is nothing fishy there. Nothing going on with DECwindows either.

I have included two attachments. One contains the accounting record while the other contains both SSH run logs (one from each node).

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Tue, 17 Oct 2006 15:48:53 GMT

Here is the accounting record attachment.

Re: Using SSH on OpenVMS V7.3-2 & V8.2

Manny DeAssis — Tue, 07 Nov 2006 18:34:30 GMT

As it turns out my problem was due to missing dss files (one for each host that communicates with the server).

The file syntax is as follows:

_ssh-dss.pub

Thanks to all who responded.