On February 9, 2016 7:28 PM, Darren Tucker wrote: > To: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> > Cc: OpenSSH Devel List <openssh-unix-dev@xxxxxxxxxxx> > 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@xxxxxxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
