This script should normally be owned by root (see https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/#configuring-ssh).

Are you starting sshd as root, or as another user? sshd must normally run as root.

@epriestley I changed the owner back to root, and yes sshd is running as root.

Is there any way to debug the hook itself?

This issue is still unresolved....

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

Until i figured this out i tried running all directories with less permissions (750) - which did result in a

AuthorizedKeysCommand /usr/share/phabricator-ssh-hook.sh returned status 126

I really don't know which user is here trying to invoke whichever script or command (since all defined users [git, phd, www-data] are nicely coupled in their phacility-group), but since i wasn't able to track that down i think that's a good compromise. And it should be safer than letting root invoke the AuthorizedKeysCommand.

Yes, you should NOT set AuthorizedKeysCommandUser root, this is needlessly dangerous and gives the script substantially more permission than it needs.

I am going to hide the comment suggesting this solution above; users should not follow this advice.

This definitely works without root: we run it without root on dozens of production servers. If you have an environment where the instructions don't work, provide complete reproduction steps (see Providing Reproduction Steps) so we can reproduce and understand the issue, and we'll fix the problem or instructions.

(Or just run everything as root if you don't care, but don't suggest this to other users who may not have the technical context to be able to make an informed choice about it.)

It's possible that T9560 is a more narrow description of the underlying issue.

Thanks @epriestley, i will try to investigate further. It seems that i have still something misconfigured. I'll get back as soon as i have to add something useful. :-)

I can confirm T9560 locally, at least, so that might be the problem or part of it -- maybe start there? If you can provide details we're happy to fix this properly.

I ran into the same issue and phabricator-ssh-hook.sh and its parent directory are owned by root and the script have 755 mode. The script was in /root/phabricator/ and vcs-user doesn't have access to that directory (because the /root directory is not accessible). I put the script in /etc/phabricator and it worked.

In T5463#172345, @florianb wrote:

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

Until i figured this out i tried running all directories with less permissions (750) - which did result in a

AuthorizedKeysCommand /usr/share/phabricator-ssh-hook.sh returned status 126

I really don't know which user is here trying to invoke whichever script or command (since all defined users [git, phd, www-data] are nicely coupled in their phacility-group), but since i wasn't able to track that down i think that's a good compromise. And it should be safer than letting root invoke the AuthorizedKeysCommand.

I ran into and solved the same issue, which is due to permissions.

• vcs-user is git
• phabricator-ssh-hook.sh is executed with same effective group ID git, verified by making it output id command
• Server is managed with Plesk, and it happens my phabricator directory has a parent directory with permissions drwx--x--- and group psaserv

I made git a member of psaserv:

usermod -a -G psaserv git

and made the exec command inside phabricator-ssh-hook.sh execute with the psaserv group ID, by changing:

exec "$ROOT/bin/ssh-auth" $@

to

sg psaserv "exec \"$ROOT/bin/ssh-auth\" $@"