Configure Git with SSH for Phabricator

Question

I'm trying to configure SSH for Phabricator to get git running. I've followed this manual but when I call echo {} | ssh git@phabricator.mydomain.com conduit conduit.ping I always get an empty result or Permission denied (publickey,keyboard-interactive)..

/etc/ssh-phabricator/sshd_config:

AuthorizedKeysCommand /usr/libexec/ssh-phabricator-hook
AuthorizedKeysCommandUser git

Port 22
Protocol 2
PermitRootLogin no
AllowAgentForwarding no
AllowTcpForwarding no
PrintMotd no
PrintLastLog no
PasswordAuthentication no
AuthorizedKeysFile none

/etc/passwd:

phd:x:999:999::/var/tmp/phd:/bin/false
git:x:1005:1005::/home/git:/bin/bash

/etc/shadow:

phd:!:16135::::::
git:NP:16135:0:99999:7:::

/etc/sudoers:

git ALL=(phd) SETENV: NOPASSWD: /usr/bin/git-upload-pack, /usr/bin/git-receive-pack, /bin/false

~/.ssh/config:

Host phabricator.mydomain.com
    HostName phabricator.mydomain.com
    Port 22
    IdentityFile /c/Users/.../.ssh/id_rsa_phabricator
    PreferredAuthentications publickey
    User git

UPDATE

The reasons for my problems were:

• I didn't use the SSH key with the client.
• I didn't ensure that the git user has a shell.

Answer 1

Your ssh hook is working properly - first, you should ensure that the git ssh user is able to ssh to the normal ssh daemon - this will ensure that you can login with this user.

More than likely you have a bad home directory or bad shell as stated in the comments.

If all of that is working fine, make sure you have a ssh key uploaded to your profile and that you are using this key to connect with.

Answer 2

Just another thing to note is the path must have the correct permissions for the AuthorizedKeysCommand or this could also result in

Permission denied (publickey,keyboard-interactive)

Answer 3

I ran into the

Permission denied (publickey,keyboard-interactive)

problem too and found another cause that is not yet mentioned here: SELinux.

If you use SELinux with "Enforcing" policy on your server, you might run into the same problems. To check if SELinux is responsible, set

$ setenforce 0

and try

$ echo {} | ssh git@phabricator.mydomain.com conduit conduit.ping

again.

If it suddenly works, but you don't want to permanently disable SELinux or run it in permissive mode, you can use audit2allow to resolve the issues that your server recently encountered:

$ ausearch -m avc -ts recent | audit2allow -M local
$ semodule -i local.pp

This ausearch prints recent entries from the SELinux log (usually /var/log/audit/audit.log ) and audit2allow creates policies for entries that are marked as denied. Make sure there are no recent entries in the log you don't want to allow.