Passwordless sftp fails with (null) home directory

[Gesmundo]

We have several Itanium blades running OVMS V8.3-1h1 with TCPIP V5.6-9ECO5.

We followed the procedures in setting up passwordless sftp to a Linux server.

On cluster #1, we are getting the following message:

QCQM01_> sftp vmsaud@10.94.130.174

warning: Error trying to access file (null)/ssh2/id_accd.pub.

warning: Could not read public key file (null)/ssh2/id_accd.pub

warning: Error trying to access file (null)/ssh2/id_qcqm01.pub.

warning: Could not read public key file (null)/ssh2/id_qcqm01.pub

warning: Error trying to access file (null)/ssh2/id_acmp01.pub.

warning: Could not read public key file (null)/ssh2/id_acmp01.pub

vmsaud@10.94.130.174's passwod:

On cluster #2, sftp works:

PCQM01::SUPER1 > sftp vmsaud@10.94.130.174

sftp>

Still on other stand-alone servers, the set up also is successful:

TD1MP1> sftp vmsaud@10.94.130.174

Warning: Need basic cursor movement capability, using vt100

warning: Need basic cursor movement capability, using vt100

sftp>

Any suggestions to look out for why cluster #1 is displaying (null) as home directory?

Thanks.

Noel Gesmundo

[Hoff]

Check that the Linux username you're logging into is as expected, and from the problem host and from one or more working hosts.  In particular, verify that your problematic OpenVMS connections are being reflected one-to-one on the expected Linux host, based on the ssh daemon logs on the Linux server.   Also use traceroute, as your network is clearly large enough and very likely hairy enough that there's a good chance of some wacky IP routing or some wacky VM shenanigans lurking, too.

Verify that your ssh versions are the same everywhere; working and not-working.

Long-shot, but check that the following return as expected on the hosts involved; on working and not-working hosts.

$ SHOW SYMBOL SSH

$ SHOW LOGICAL vmsaud

Then, some housekeeping...  OpenVMS I64 V8.3-1H1 is ancient, and that release soon falls off of new-patch availability for even the prior version support customers; in just a few months.  You really need to upgrade this configuration to software with support available, particularly if you're dependent on secure protocols.  (Your Linux server may also be running down-revision software, as current OpenSSH daemons should block all but the most recent ssh versions on OpenVMS — the encryption on all but the most recent SSH is sub-par.)

As an interim step and if the above tests do not identify a resolution for this, you can install TCP/IP Services V5.7 ECO5+ here — that's supported on V8.3-1H1, and it's much newer.  (It's at least ECO5. plus the Telnet fix and some updates from the support center.  New ssh, too.)

[Gesmundo]

Thanks Hoff. When I hit post, the posted format becomes a mess. How do I maintain the readable format like all the posts? We have plan to install TCPIP 5.7 eco 5 and hopefully resolve this issue. All VMS servers have the same version of TCPIP. vmsaud is not defined on all nodes. Noel

[Hoff]

What I've found as the easiest way to avoid oddly-formatted or corrupted postings: don't use Lithium.   Otherwise, expect to get the occasional weirdness.   Some of the web-based forums just have browser-specific bugs, or generic bugs.   Try a different browser.   Lithium gets confused over pasted text, for instance.

As for alternative sources of information, there are other OpenVMS-related discussion forums such as the Notes conferences available at decuserve.org, and the comp.os.vms newsgroup is also available via free accounts at Eternal September or also via the semi-flaky Google Groups forum interface.

As for the future here at HPSC, there's also that HP (HPE) is ramping down their OpenVMS involvement per the HP (HPE) roadmap, and there's the transition to VSI for all new OpenVMS releases and for the x86-64 port that's underway.

[Dennis Handly]

> the posted format becomes a mess. How do I maintain the readable format like all the posts?

You can aways go back and edit it with Post Options > Edit Reply.

I've had cases where I post and it's messed up with no newlines and when I redo it it works.  ??

Otherwise there is a menu button above that looks like {i} that will allow you to paste in blocks of code/text.

[Gesmundo]

Hoff,

We shutdown one of the nodes and booted it from its local disk as standalone with the same TCPIP configuration. The local disk being a backup image of the common system disk.

Without doing another setup and using the same key in the sftp server, we were able to connect to the server without password.

We then applied TCPIP V5.7 and rebooted the system as still standalone. Again we were able to connect to the server without password.

The system was rebooted back to the cluster and ,as expected, the connection asked for the password with the (null) home directory shown:

warning: Could not read public key file (null)/ssh2/id_qcqm01.pub

warning: Error trying to access file (null)/ssh2/id_acmp01.pub.

warning: Could not read public key file (null)/ssh2/id_acmp01.pub

sgxuser's password:

Our cluster is on 2 sites hence on 2 LANs. Could this be related to this cluster setup?

We still plan to apply TCIP V5.7 to the whole cluster for testing.

Thanks

Noel

(( fixed format with Chrome))

[Steven Schweda]

> [...] (( Edit reply obviously did not work after several tries and
> could not attach file too))

   Doing/using what, exactly?  I normally edit this stuff in a DECterm
or Xterm, and then copy+paste into the forum in a Firefox browser on a
Mac.  You can see how that works.

   If you can find a way to post multiple lines as multiple lines, then
it might help to see a transcript of "ssh -v [...]" or "sftp -v [...]"
in both cases (working and not).  Also possibly interesting would be
some info on what SYS$LOGIN is, what's in the [.ssh2] directory (under
SYS$LOGIN), what's in [.ssh2]IDENTIFICATION., and probably other things
of which I can't think now.  If the cluster environment affects the
user's home directory or UIC, then many things could go wrong.


> [...] OpenVMS I64 V8.3-1H1 is ancient [...]

   Yeah, but until I upgraded my Mac to El Capitan, I was doing well
enough around here on V8.3 Alpha.  Not relevant here, but SSH on VMS to
the newer OpenSSH/LibreSSL on the Mac fails:

alp $ ssh pro3
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm
 negotiation failed.).

   Still works in the other direction, though.

[Ian Miller.]

TCPIP V5.7 ECO5 fixes a bunch of things so uprading will be a good idea.

The support status of OpenVMS V8.3-1H1 changes at the end of this year. Do seriously consider upgrading to OpenVMS V8.4

[Gesmundo]

After several testing, we were able to make the passwordless sftp work without upgrading to TCPIP V5.7.

We used  logical name for the device for the account in the UAF file. SSH is able to see the home directory if the device name is a logical name. DSAxx (shadow set) is interpreted as (null) by SSH in a multi site cluster.

The logical name must be in the system logcal name table.

Thank you for all the recommendations.

Noel

(used Chrome and the format is not a mess anymore)