Page MenuHomePhabricator

Change sshd templates so they use the new ssh-auth syntax
Needs ReviewPublic

Authored by kuba-orlik on Aug 12 2020, 7:04 PM.
Referenced Files
F13464348: D21445.diff
Mon, Jul 15, 10:37 PM
F13386676: D21445.diff
Mon, Jul 1, 5:36 AM
F13369507: D21445.id51044.diff
Thu, Jun 27, 12:11 PM
Jun 14 2024, 4:20 PM
F13314786: D21445.diff
Jun 12 2024, 1:24 AM
Jun 11 2024, 3:15 PM
F13306948: D21445.diff
Jun 9 2024, 12:00 PM
F13303756: D21445.diff
Jun 8 2024, 7:12 AM


Group Reviewers
Blessed Reviewers
Required Signatures
L28 Phacility Individual Contributor License Agreement

We've been encountering an issue with phabricator's ssh
daemon being very unreliable on our install. I've been trying to debug
it for a good part of the last week now and finally solved it. The fix
was to update the sshd config to use the new ssh-auth argument syntax.

The issue was that 9 times out of 10 the server didn't accept the
users's keys, responding with:

Permission denied (publickey).

After setting the sshd log level on the server to VERBOSE I could see the following:

debug1: matching key found: file /usr/libexec/, line 2 <redacted>
error: AuthorizedKeysCommand /usr/libexec/ git failed, status 255
debug1: restore_uid: 0/0

After reading the source of scripts/ssh/ssh-auth.php, I realized
that when given a key as an argument, the script returns only the
matching key instead of all the keys in the database. But the default
sshd config templates mentioned in this article
do not take advantage of that feature.

After changing the sshd config so it passes the user key to the php script, the problems went away.

Test Plan

Used the config templates on a server, restarted the sshd daemon and successfully connected to the server via ssh (e.g. by cloning a repo over ssh)

Diff Detail

rP Phabricator
Lint Passed
No Test Coverage
Build Status
Buildable 24859
Build 34292: arc lint + arc unit

Event Timeline

The root cause is a bug in SSHD which was fixed in January 2017, see T11827.

This change is conceptually fine but I'm not entirely sure the %k change works everywhere and I'm hesitant to risk replacing a well-understood headache rooted in an SSHD bug which tends to be resolved in the obvious way ("upgrade sshd") with a poorly-understood headache rooted in, say, keys which have two or more different variations that SSHD accepts.

%k has been in production in Phacility for a while without issues and I expect to recommend this configuration or some similar configuration in the future, but I'd like to pull production data first and convince myself that all the cases which are falling through are for keys legitimately not present in the key list.

Mostly for my own notes:

In PHI1785 (internal) we did this, which is perhaps slightly simpler:

AuthorizedKeysCommand /usr/libexec/ %u --sshd-key %k

But I think the whole $VCSUSER check is not really necessary, and it might be reasonable to simplify the indirection hook.