Test Failure OpenSSH 7.1 P2 on HPE NSE for key-commands

[Randall S. Becker]

On February 9, 2016 7:28 PM, Darren Tucker wrote:
> To: Randall S. Becker <rsbecker at nexbridge.com>
> Cc: OpenSSH Devel List <openssh-unix-dev at mindrot.org>
> Subject: Re: Test Failure OpenSSH 7.1 P2 on HPE NSE for key-commands
> 
> On Wed, Feb 10, 2016 at 10:35 AM, Randall S. Becker
> <rsbecker at nexbridge.com> wrote:
> > Thread split from my previous communication. Here is the key-commands
> > logs on the platform.
> 
> [...]
> 
> OK, in this case the interesting bit is in the failed-sshd.log.
> 
> > Unsafe AuthorizedKeysCommand "/var/run/keycommand_SUPER.SUPER":
> bad
> > ownership or modes for file /var/run/keycommand_SUPER.SUPER
> >
> > debug1: restore_uid: 65535/255
> 
> sshd ensures that the AuthorizedKeysCommand can't be modified by a non-
> privileged user for obvious reasons.
> 
> Based on what you said earlier, your root (equivalent?) user is not uid 0.  I
> suspect that the permissions on the keycommand file to not match sshd's
> expectations.  The code that checks this is in
> auth2-pubkey.c:subprocess() which calls auth.c:auth_secure_path().
> 
> What are the file permissions on /var/run/keycommand_SUPER.SUPER and
> its parent directories?  Did you run the test with SUDO=sudo?  Where did
> SUPER.SUPER come from?

SUPERUSER ends up being 65535, which is root on this platform. SUPER.SUPER is the actual name of root. /var and /var/run are both 755, while /var/run/keycommand_SUPER.SUPER is 644.

We do have to run the whole test suite under sudo anyway.