SFTP - Open VMS - Unable to write host key

[Pradeep K P]

Hi Friends,

I setup a new public key based authorization with windows host. I could successfully connect to windows host, but i'm getting some message like this,

warning: Error trying to access file ssh2/hostkeys/key_22_xxx_xxxxxxp_xxxxxx_xxx_xxxxxxxxx_xxx.pub.
debug: SshKeyFile/SSHKEYFILE.C:440: file ssh2/hostkeys/key_22_xxx_xxxxxxx_xxxxxx_xxx_xxxxxxxxx_xxx.pub does not exist.
warning: Error trying to access file /etc/ssh2/hostkeys/key_22_xxx_xxxxxxx_xxxxxx_xxx_xxxxxxxxx_xxx.pub.
debug: SshKeyFile/SSHKEYFILE.C:440: file /etc/ssh2/hostkeys/key_22_xxx_xxxxxxx_xxxxxx_xxx_xxxxxxxxx_com.pub does not exist.
Host key not found from database.
Key fingerprint:
xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
You can get a public key's fingerprint by running
$ ssh_keygen "-F" publickey.pub
on the keyfile.
debug: SshKeyFile/SSHKEYFILE.C:528: could not open ssh2/hostkeys/key_22_xxx_xxxxxxx_xxxxxx_xxx_xxxxxxxxx_xxx.pub.
warning: Unable to write host key ssh2/hostkeys/key_22_xxx_xxxxxxx_xxxxxx_xxx_xxxxxxxxx_xxx.pub

I understood that somehow the hostkey from the windows server is not getting updated in ssh2/hostkeys directory. (hostkeys from someother servers are already there, so i don't suspect any permission issue)

Looking forward to get some technical insight to resolve this issue. Thanks in advance.

[John Gillings]

Pradeep,

Do you have file access failure auditing enabled?

$ SET AUDIT/ALARM/ENABLE=FILE=FAIL=ALL
$ REPLY/ENABLE=SECURITY

Now retry your command and see if you get any audit alarms. They should pinpoint the exact reason for any access failures.

You may also want to check the file attributes. I've only gone the other way (VMS generated key file, transferred to Windows), the problem was in the file format - getting into a state that both Windows and VMS agreed on.

[Steven Schweda]

I know nothing, but if your home directory
(SYS$LOGIN) is on an ODS2 disk, then a name
like
key_22_xxx_xxxxxxx_xxxxxx_xxx_xxxxxxxxx_com.pub
is too long (43.3 > 39.39). (I assume, of
course, that each "x" represents an actual
name character.) Assuming that this is the
problem here...

I don't know what you can do to get the SSH
software to use a shorter name. Perhaps an
alias (a _short_ alias) in the local HOSTS
data base? Can you get the people at
"xxxxxxxxx.com" to set up a shorter alias in
the DNS at that end? (Or are you already at
"xxxxxxxxx.com"? Actual names can be so
much more informative than anonymized names.)

(Ha! You slipped up on the "_com". I wonder
how many "xxxxxxxxx.com" domains there are.)

Have you considered the many possible
benefits of having a home directory on an
ODS5 disk?

Potentially useful info:

pipe show device /full sys$login | search sys$input ods

TCPIP SHOW VERSION (unless you're using some
other IP procduct)

ssh "-V"

sftp "-V"

[Pradeep K P]

Hello John, i tried enabling the audit alarm and connecting again. Unfortunately, i couldn't find anything mathing our intrest. Here also the key which i sent to windows works fine, and the problem is with the hostkeys which windows sending to open vms when initiating the connection. Thanks & Really appreciate your thought.

Hello Steven, you are correct, 'x' represents each char at the actual name. The original name of the host is comapritively a shorter than the host key name.
(Host name - xxx_xxxx_xxx.xxx.xxxxxxxxx.com)
(Hostkey name - key_22_xxx_999xxxx_999xxx_xxx_xxxxxxxxx_xxx.pub). I think the key is transferred, when i tries to connect to the windows host (Really i dont have any idea where these numericals inserted into the host key name).Thanks for your ideas. (Hope, better we need to move to ODS5 drives)

TCPIP version is
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6

SSH version
Ssh2/SSH2.C:1906: CRTL version (SYS$SHARE:DECC$SHR.EXE ident) is V7.3-2-03

SFTP version
Sftp2/SFTP2.C:4642: CRTL version (SYS$SHARE:DECC$SHARE ident) is: V7.3-2-03

Once again thanks.

Pradeep.

[Steven Schweda]

> (Really i dont have any idea where these
> numericals inserted into the host key name)

That's two of us. I created a long alias for
"alp" in my local hosts data base, and got
the expected errors:

alp $ ssh -v ALP12345678901234567890123456789012345
[...]
warning: Error trying to access file ssh2/hostkeys/key_22_alp1234567890123456789
0123456789012345.pub.
debug: SshKeyFile/SSHKEYFILE.C:440: file ssh2/hostkeys/key_22_alp123456789012345
67890123456789012345.pub does not exist.
warning: Error trying to access file /etc/ssh2/hostkeys/key_22_alp12345678901234
567890123456789012345.pub.
debug: SshKeyFile/SSHKEYFILE.C:440: file /etc/ssh2/hostkeys/key_22_alp1234567890
1234567890123456789012345.pub does not exist.
Host key not found from database.
[...]

but I didn't get any unexpected characters in
the too-long file name.

It appears that the file name is formed from
the host name which you specify, so if you
can find a way to use a shorter host name,
then it should try to use a shorter file
name.

> SSH version
> [...]

It probably doesn't matter, but I quoted the
"-V" in
ssh "-V"
for a reason. (Now, if _I_ had written the
code, ...)

[Richard Whalen]

Process Software's SSH product recognizes that really long host names can cause problems with how the keys are stored and has a method of encoding the file names when this happens.