search for: auth_secure_path

...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 a...

...king perfectly! One tweak I had to do, since the AuthorizedKeysCommand feature requires file to be owned by root, I had to use root owned command at root owned directory, although it does not add a security value. At auth2-pubkey.c::user_key_command_allowed2(), we have the following: if (auth_secure_path(options.authorized_keys_command, &st, NULL, 0, errmsg, sizeof(errmsg)) != 0) { error("Unsafe AuthorizedKeysCommand: %s", errmsg); goto out; } This enforce root uid explicitly (arg#4). Will it be acceptable to use geteuid() instead...

Thread split from my previous communication. Here is the key-commands logs on the platform. ***************** failed-regress.log ************ trace: AuthorizedKeysCommand with arguments FAIL: connect failed trace: AuthorizedKeysCommand without arguments FAIL: connect failed ***************** failed-ssh.log ************ trace: AuthorizedKeysCommand with arguments