Cant run SSH OpenVMS 8.4 TCPIP 5.7 ECO2

[Arne Korpas]

Hi all,

I have a problem running SSH on an Integrity running OpenVMS 8.4/TCPIP 5.7 ECO2.
I can start SSH, but cant communicate with this machine via SSH, it seem to be some kind of problem with the hostkeys.
Does anyone recognize this problem ?

Here's what I get in the TCPIP$SSH_RUN.LOG

Mon 14 12:44:24 WARNING: ssh_privkey_read from¶ÍzàµÙ failed.
Mon 14 12:44:24 ERROR: FATAL ERROR: Unable to load any hostkeys
dsa0:[sys0.syscommon.][sysexe]tcpip$ssh_sshd2.exe[6849]: FATAL: Unable to load a
ny hostkeys
%TCPIP-F-SSH_FATAL, non-specific fatal error condition

And if I try to run locally (ssh -l user host) I get an access violation
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000007ACD
C000, PC=FFFFFFFF84E64640, PS=0000001B

Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000005

BR /Arne Korpas

[Duncan Morris]

Hi Arne,

I am running 5.7ECO2 on 8.3-1H1 without any problem.

Did you ever have SSH working on this system?

Have you generated the hostkey?

On my system:

Directory SYS$SYSDEVICE:[TCPIP$SSH.SSH2]

hostkey.;2 3 30-SEP-2010 14:19:55.12 [TCPIP$AUX,TCPIP$SSH (RWED,RWED,,)
hostkey.pub;2 3 30-SEP-2010 14:19:55.21 [TCPIP$AUX,TCPIP$SSH (RWED,RWED,RE,)

Total of 2 files, 6 blocks.

Does your SSHD2_CONFIG file have the definitions

HostKeyFile hostkey
PublicHostKeyFile hostkey.pub

Try running

ssh2 -v localhost

and post the output as an attachment, so that we can see the detailed error messages.

Duncan

[Arne Korpas]

Hi Duncan,

No I dont think anyone have ever run SSH on this machine before. I compared my config with yours and I have exactly the same.
Something seems to be weird with this machine, did you notice the garbage in the output from the first logfile ? (ssh_privkey_read from...)

I get an access violation if I run ssh2 -v localhost (see the attached file).

BR /Arne

[Duncan Morris]

Arne,

that certainly looks serious!

On my system the ssh2 - v locahost starts with:

debug(14-FEB-2011 13:27:57.48): Ssh2/SSH2.C:1896: CRTL version (SYS$SHARE:DECC$SHR.EXE ident) isELF
debug(14-FEB-2011 13:27:57.48): SshAppCommon/SSHAPPCOMMON.C:313: Allocating global SshRegex context.

What account are you trying to run SSH from? There have been strange behaviours observed when the account rights identifier differs from the VMS username.

See:

http://h30499.www3.hp.com/t5/General/SSH-on-VMS-7-3-2/m-p/4318717#M15903

[Oswald Knoppers_1]

You could also check user quota.

Oswald

[Arne Korpas]

Hi Duncan,
that was strange, I was running from a copy of the system account and got the accvio errors. When I run from the system account the keys are generated as expected, and I can run ssh2 -v localhost. But there is some kind of problem with the keys, look at this,
(unable to open...)

iGsmdb à » ssh2 -v localhost

debug(14-FEB-2011 14:57:58.37): Ssh2/SSH2.C:1896: CRTL version(SYS$SHARE:DECC$S
HR.EXE ident) is ELF
debug(14-FEB-2011 14:57:58.38): SshAppCommon/SSHAPPCOMMON.C:313: Allocating global SshRegex context.
debug(14-FEB-2011 14:57:58.38): SshConfig/SSHCONFIG.C:3461: Metaconfig parsing stopped at line 4.
debug(14-FEB-2011 14:57:58.38): SshConfig/SSHCONFIG.C:887: Setting variable 'VerboseMode' to 'FALSE'.
debug(14-FEB-2011 14:57:58.39):

SshConfig/SSHCONFIG.C:3369: Unable to open ssh2/ssh2_config

debug(14-FEB-2011 14:57:58.39): Connecting to localhost, port 22... (SOCKS no
t used)debug(14-FEB-2011 14:57:58.39): Ssh2/SSH2.C:2881: Entering event loop.
debug(14-FEB-2011 14:57:58.39): Ssh2Client/SSHCLIENT.C:1609: Creating transport protocol.
debug(14-FEB-2011 14:57:58.40): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "publickey" to usable methods.
debug(14-FEB-2011 14:57:58.40): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added
"keyboard-interactive" to usable methods.
debug(14-FEB-2011 14:57:58.40): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "password" to usable methods.
debug(14-FEB-2011 14:57:58.40): Ssh2Client/SSHCLIENT.C:1650: Creating userauth protocol.
debug(14-FEB-2011 14:57:58.40): client supports 3 auth methods: 'publickey,keybo
ard-interactive,password'
debug(14-FEB-2011 14:57:58.40): SshUnixTcp/SSHUNIXTCP.C:1750: using local hostname igsmdb.sun.telia.se
debug(14-FEB-2011 14:57:58.40): Ssh2Common/SSHCOMMON.C:541: local ip = 127.0.0.1, local port = 49200
debug(14-FEB-2011 14:57:58.40): Ssh2Common/SSHCOMMON.C:543: remote ip = 127.0.0.1, remote port = 22
debug(14-FEB-2011 14:57:58.40): SshConnection/SSHCONN.C:2578: Wrapping...
debug(14-FEB-2011 14:57:58.40): SshReadLine/SSHREADLINE.C:3662: Initializing ReadLine...
debug(14-FEB-2011 14:57:58.45): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received:
Connection closed by remote host.
debug(14-FEB-2011 14:57:58.45): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
warning: Authentication failed.
debug(14-FEB-2011 14:57:58.45): Ssh2/SSH2.C:327: locally_generated = TRUE
Disconnected; connection lost (Connection closed by remote host.).

debug(14-FEB-2011 14:57:58.45): Ssh2Client/SSHCLIENT.C:1685: Destroying client.
debug(14-FEB-2011 14:57:58.45): SshConfig/SSHCONFIG.C:2867: Freeing pki.(host_p
ki != NULL, user_pki = NULL)
debug(14-FEB-2011 14:57:58.45): SshConnection/SSHCONN.C:2630: Destroying SshConn object.
debug(14-FEB-2011 14:57:58.45): Ssh2Client/SSHCLIENT.C:1753: Destroying client completed.
debug(14-FEB-2011 14:57:58.45): SshAuthMethodClient/SSHAUTHMETHODC.C:109: Destroying authentication method array.
debug(14-FEB-2011 14:57:58.45): SshAppCommon/SSHAPPCOMMON.C:326: Freeing global SshRegex context.
debug(14-FEB-2011 14:57:58.45): SshConfig/SSHCONFIG.C:2867: Freeing pki. (host_pki = NULL, user_pki = NULL)

The file is readable, and the system account have bypass so it shouldn't be a prot problem. My system disk is at ODS-5, do you know if that could cause anything ?

iGsmdb à » dir/sec/own ssh2_config

Directory SYS$SYSDEVICE:[TCPIP$SSH.SSH2]

SSH2_CONFIG.;1 [TCPIP$AUX,TCPIP$SSH] (RWED,RWED,RE,R)


BR /Arne

[Duncan Morris]

Arne,

looks like you have proper connection now.

The Unable to open ssh2/ssh2_config refers to SSH looking for a private version of the config file, after having already read the global config file. It is not necessary to have a private config file.

It is not an error message, just an observation. You are only seeing it because it appears in the debug output.

Your authentication is failing to match the key. Let me guess that you do not have your own account in AUTHORIZATION., which is being checked during the login.

XXXXXX-MORRISD> ty [.ssh2]identification.
IdKey id_morrisd_xxxxxx

XXXXXX-MORRISD> ty [.ssh2]authorization.
Key id_morrisd_xxxxxx.pub
Key id_morrisd_yyyyyy.pub

XXXXXX-MORRISD>

This allows me to do an SSH to localhost, matching the ID id_morrisd_xxxxxx to the authorization id_morrisd_xxxxxx.pub

Duncan

[Arne Korpas]

Hi Duncan,
I'm running from the system account and it has its own identifier. I cant find the files identification. or authorization.

here's what I have in [.ssh2]
ID_DSA_2048_A. and ID_DSA_2048_A.PUB

Do you see anything strange in my configfile ? (attached)

[Duncan Morris]

Arne,

you must create IDENTIFICATION to name which private keys you will present to remote hosts.

you must create AUTHORIZATION to name which public keys you will use to accept identification from remote hosts.

I am attaching a document which shows how to generate a key pair and populate your id/auth files.

Regards,

Duncan

[Rick Retterer · Accepted solution]

Arne,
Are you running with your system disk shadowed? If so, then this is a known problem and you need to open a case with the HP OpenVMS TCPIP Support team to obtain a patch that fixes this problem.

When you log your case, send them the exact error message that you have provided here. And if you are running with your system disk shadowed, it's caused by a problem that is fixed in a new version of the DECC$SHR.EXE, that was provided in: QXCM1001078785

Cheers,
Rick

[Arne Korpas]

I submitted a case to HP and I got the DECC$SHR patch from them, installed it and everything is ok now :)
Thank you all for your engagement in this issue.

Cheers /Arne

[Hoff]

Um, so would somebody mind elaborating on the "known problem" here?

And which versions and architectures are involved other than V8.4?

That the C library DECC$SHR can apparently trigger ACCVIO access violation errors (in a VMS security component!) when the system disk is shadowed covers a whole lot of territory and a whole lot of servers.

[Arne Korpas]

Here's the note from HP

This is a know issue after applying VMS84I_UPDATE-V0400 to OpenVMS with a shadows systemdisk
Article extract:
Problem description:
After installing Update Kit V4 in OpenVMS 8.4 Integrity, SSH will stop working if running TCPIP V5.7 ECO1.
Typing the SSH log file shows:

TCPIP$SSH_DEVICE:[TCPIP$SSH]TCPIP$SSH_RUN.LOG

Fri 08 18:09:27 WARNING: ssh_privkey_read from ssh2/hostkey failed.
Fri 08 18:09:27 ERROR: FATAL ERROR: Unable to load any hostkeys
dsa0:[sys0.syscommon.][sysexe]tcpip$ssh_sshd2.exe[320]: FATAL: Unable to load any hostkeys
%TCPIP-F-SSH_FATAL, non-specific fatal error condition
TCPIP$SSH job terminated at 8-OCT-2010 18:09:27.83
Solution
This issue was elevated to OpenVMS Engineering and a fix has been provided.
Engineering analysis:
We created a dump file and our analysis revealed that a crash was occurring in OpenVMS CRTL DECC$SHR.EXEin stat() API routine. OpenVMS CRTL tries to find the "$ " character in a loop to retrieve the node name from the disk name, however for a shadow set device, this logic would fail because the shadow set device naming convention does not include a node name in the "shadow set device name " (ssdn), and as a node name is not present at all in a ssdn it would never find the terminating "$ ". Hence the loop would not end and corruption would occur.
Solution description:
We found that the algorithm to retrieve the node name from the disk-name did not have a check for the boundary condition. This would cause the loop to corrupt the data and hence the crash.

[Duncan Morris]

Hoff,

looks like it is covered in the latest ACRTL for itanium 8.31H1

5.2.7 Stat() ACCVIO.s for a file on Shadow Set

5.2.7.1 Problem Description:

The algorithm to obtain the st_dev for a file on Shadow
Set device (when the ALLOCATION Class of the device is
ZERO) does not check for the boundary condition resulting
in ACCVIO.

Images Affected:

- [SYSLIB]DECC$SHR.EXE

Also present for Alpha 8.3 and I64 8.3 in the latest ACRTL updates.

Presumably, the corresponding updates are in the pipeline for 8.4.

[Hoff]

So stat() is broken.

Interesting.

This bug may well hit any device that doesn't use an allocation class prefix or the SCSNODE prefix, based on reading the replies.

DSs are only one example of that ilk.

A stat against LD, too, would probably break.

Somebody directly and incorrectly parsed a device name somewhere deep in the RTL, and got caught. Ah, well.