[Info-vax] stumped by SSH

[Phillip Helbig undress to reply]

Let me recap:

Login works via other methods, but not by SSH.  When attempting by SSH, 
the standard 

   %LOGIN-F-NOTVALID, user authorization failure

message occurs.  On the linux client side, it is "permission denied" (a
VMS client gives no message, just repeats the password prompt). 
Obviously, username and password are correct, otherwise logging in via
SET HOST/LAT, TELNET, etc. wouldn't work. 

This account is set up analogously to another account which doesn't have 
the problem.  Among other accounts, some work and some don't.  So, it 
doesn't seem to be a problem with this particular account, but rather in 
general some accounts work and some don't.

I have concentrated on this account and a similar account since they are
both relatively new and bare bones and I didn't find any differences
which seemed relevant.  Not that there were no differences.  For
example, the one which works has a MAIL.MAI file but the one which works
doesn't, but I can't see how this could be relevant (and among the 
other accounts, all have MAIL.MAI and some work and some don't).

The only other difference is the presence of
DECW$XAUTHORITY.DECW$XAUTH;1 in the simple account which works and the 
lack of it in the simple account which doesn't work.  This doesn't seem 
relevant, as I am looging in via the command line, but you never know.
I then checked to see which accounts have this file.  Some do, some 
don't.  In each category, there are some accounts for which I know the 
password and some for which I don't.  So [drumroll, please], I went 
through all to see which work and, lo and behold, I can log in via ssh 
if and only if DECW$XAUTHORITY.DECW$XAUTH;1 is present.

Does this make sense?

Is it documented?

Should the error messages (both client and server) be different?

Presumably this file gets created when setting display settings in 
DECwindows.  I suppose I can try to set this up in the accounts which 
don't work (manipulating them to allow this) and see if it helps.  
However, I don't recall ever having logged in to the bare-bones account 
which does work, so I'm not sure where the DECW$XAUTHORITY.DECW$XAUTH;1 
file comes from.

Interestingly, the CREATION dates for this file in the corresponding 
accounts is quite recent (hours to days old), except for one of the 
accounts, where it is a few months old.  (The modification time is 
always shortly after the creation time.)  In some cases, but not all, 
this timestamp corresponds to the last successful login a) from outside 
my cluster and b) from a specific remote adddress.  (In other words, in 
one case the timestamp corresponds to a known login time from outside, 
but logging in (from elsewhere) to the same account today did not update 
that timestamp.  Could this depend on some ssh option on the client 
side.)

As a quick test, I copied this file from another account into the
account which doesn't work, but with no effect.  I didn't expect it to 
work, though.

Commnents?  Suggestions?  Questions?