[Info-vax] stumped by SSH

[George Cornelius]

In article <n9a3sh$3uk$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2016-02-07, David Froble <davef at tsoft-inc.com> wrote:
>> I'm assuming that some prived user account is setting up the UAF record, AND, 
>> creating the default directory for the new user account.  Normally, the new UAF 
>> UIC and the new directory would have the same UIC.  I've screwed that up in the 
>> past.
> 
> And that's exactly why the UICs should be different between the two accounts.

I think we are focusing on file permissions, since that appears
to be what the failure message was about.  If it had been
an authentication failure you would have seen attempts to
try the other forms of authentication in the list, plus
it would have allowed retries.

The obvious thing that comes to mind is that somewhere is a
reference to data structures or files from the old account
that is being used at the time SSH is performing authentication.

I don't know what that might be, but placing ACL's on the
other directory structure might change the symptoms or even
allow the login to succeed.  Turning on audits of access
failures or all accesses to the original and cloned files
(can use ACL's for this, as I recall) might show something.

I might at this point ask for a reproducer.  Make the simplest
possible user account which, upon cloning, reproduces the
problem.  This can eliminate a lot of extraneous issues that
have to be considered when you deal with real, preexisting
accounts.

Think about what cloning does.  It copies the UIC by default,
retains various settings including device, directory,
LGICMD, and held identifiers. It preexpires the (no longer
valid) password.  If the UIC is the same, it will refuse
to create an identifier to match the new username, and this
anomaly will continue even if you later change the UIC
as a separate step.  There is, however, a variant to

  UAF> ADD/IDENTIFIER

that can automatically correct this latter issue.

When testing, consider using a script that does all of
these things in a predictable fashion, say by prefixing
existing usernames, LGICMD, etc., with an X, adding 1 to
the to the member number or group number, and cloning the
directory tree without any files except LGICMD, while
setting new files to the correct ownership.  It could
set only some minimal collection of held identifiers.
It could also set up alarm ACL's (is that what they are
called?) to generate audit entries when any files in
the tree are accessed.  As mentioned above, similar
ACL's could have been set independently on the
original directory and its files.

If you would complain that the original is being
modified as part of the testing, that merely
underlines the need  to start with a known minimal
test account that reproduces the problem instead of
starting with something real and therefore adding
unnecessary complexity.

With regard to complexity, I recommend testing
pure vanilla, non-captive accounts.  There are some
stringent requirements for the latter that are best
avoided at this point.

George