Page MenuHomePhabricator
Create Task
Maniphest T11147

SSH configuration with single SSH server instance
Closed, WontfixPublic
Actions

Description

Hi,

not sure if that's the correct task type but I recently set up Phabricator on a self hosted machine and when looking at the SSH config for git I was surprised to see that the suggested configuration is using another SSH instance on a different port. This can all easily be done within the existing SSH instance with just a few lines of code (see below). Might be something worth adding to the documentation.

Just adding this to the sshd_config works like a charm:

Match User git
        AuthorizedKeysCommand /etc/ssh/phabricator-ssh-hook.sh
        AuthorizedKeysCommandUser git
        AllowUsers git

The user in my case is git but could be any user desired.

Result:
Normal SSH connections and git related actions can be managed by only one SSH instance.

Event Timeline

4xoc created this task.Jun 14 2016, 2:36 PM
asherkin added a subscriber: asherkin.Jun 14 2016, 2:48 PM
avivey added a subscriber: avivey.Jun 14 2016, 8:16 PM

Which versions of sshd support this configuration?

4xoc added a comment.Jun 15 2016, 4:52 AM

According to release notes it was added in OpenSSL with version 4.4 (http://www.openssh.com/txt/release-4.4).

Just to have said that too, a match directive always considers all following parameters to be part of this match, until another match directive is reached. It's therefore important to put this configuration to the end of the sshd_config.

allixsenos added a subscriber: allixsenos.EditedJun 15 2016, 2:20 PM

without getting into whether it *can* be done, we looked into this recently and decided we actually liked the suggested approach.

the reasoning is:

  1. our server does not have a public IP and is otherwise not accessible from the public internet
  2. the only publicly accessible service (before setting ssh up) was https via load balancer
  3. if we were to expose port 22 that would mean someone could log in as root or any other account on the system, knowing the password or key
  4. using a separate sshd instance for phabricator, and exposing just that one means the ssh we expose publicly can *only* be used for git, nothing else

after a short debate, we decided to go with the proposed setup. been running it for a few weeks, no complaints so far.

epriestley closed this task as Wontfix.Jun 15 2016, 3:41 PM
epriestley claimed this task.
epriestley added a subscriber: epriestley.

I think this also increases the chance that users accidentally disable or misconfigure (e.g., by misusing Match user) administrative sshd by requiring more extensive changes to its configuration. Users locking themselves out of the host is the worst outcome of a configuration attempt by a huge margin.

You've also omitted, e.g., AllowTcpForwarding. This is probably fine if the SSH hook is configured correctly since it should explicitly prevent forwarding, but maybe not fine if combined with other deviations from configuration or mistakes.

(AllowUsers in a Match user block is also probably redundant? Unless you have a previous DenyUsers * or similar. It's not obvious to me that Match user would evaluate on a user that had been denied at the time that Match user was evaluated.)

Ultimately, the document doesn't claim to be an exhaustive description of every possible way to configure sshd, nor could it reasonably be.

I think running two copies of sshd is desirable at the high end so they can be firewalled separately, as @allixsenos notes. Beyond external attackers, clustered repositories also need to execute VCS operations directly on other nodes, but do not need administrative access. Although the number of attacks this realistically mitigates is likely small or nonexistent when things are correctly configured, I think it is somewhat more difficult to misconfigure access when the services are separated -- for example, it means you can open up a very narrow new service, rather than opening up administrative SSHD which was originally deployed under the assumption that it would be firewalled.

Separating them additionally supports having the VCS SSHD ignore the SSH username, as GitHub does, or interpret the SSH username to provide instancing, as the Phacility cluster does. These are extreme-high-end use cases because sshd can't do either of these without patches today, but it may be able to in the future, and it can be patched to do this fairly easily.

I think this is also the approach that is least likely to lead to a less experienced user locking themselves out of their machine or compromising their own sshd, because it minimizes how much you have to mess with the primary administrative sshd configuration.

For experienced administrators deploying small installs who have enough information to make an assessment about cluster configuration tradeoffs, Match user might be a better approach, but these users are best-equipped to fend for themselves and I think the benefit is likely not worth the additional complexity.

Phabricator · Built by Phacility