Page MenuHomePhabricator

Improve SSH configuration
Needs RevisionPublic

Authored by joshuaspence on Jul 26 2015, 12:23 PM.
Tags
None
Referenced Files
Unknown Object (File)
Aug 5 2024, 5:26 AM
Unknown Object (File)
Jul 27 2024, 8:04 AM
Unknown Object (File)
Jul 25 2024, 12:24 AM
Unknown Object (File)
Jul 20 2024, 11:48 AM
Unknown Object (File)
Jul 16 2024, 12:45 AM
Unknown Object (File)
Jul 6 2024, 4:04 AM
Unknown Object (File)
Jun 1 2024, 3:32 AM
Unknown Object (File)
May 29 2024, 1:45 PM

Details

Reviewers
epriestley
Group Reviewers
Blessed Reviewers
Summary

Instead of recommending that an alternative SSH service be run, provide proper instructions for running adminstrative SSH on the same port as Phabricator SSH.

Test Plan

This is the same configuration that I use on my dev VM.

Diff Detail

Repository
rP Phabricator
Branch
master
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 7400
Build 7840: [Placeholder Plan] Wait for 30 Seconds
Build 7839: arc lint + arc unit

Event Timeline

joshuaspence retitled this revision from to Improve SSH configuration.
joshuaspence updated this object.
joshuaspence edited the test plan for this revision. (Show Details)
joshuaspence added a reviewer: epriestley.
eadler added a reviewer: eadler.
eadler added a subscriber: eadler.

overall seems reasonable, and the /etc/shadow issue predates your change. This sort of instruction would also make it easier to use when firewalls are in the way

src/docs/user/userguide/diffusion_hosting.diviner
108–112

It would be good to mention that not all installations have /etc/shadow

epriestley edited edge metadata.

I think there are three generally reasonable ways to configure this:

  1. Use different ports, with VCS access on a nonstandard port.
  2. Use different ports, with operations access on a nonstandard port.
  3. Use the same port, with "Match User".

I don't think (3) is universally desirable. In particular:

  • It carries the highest risk of locking yourself out of the box while trying to configure it, since you have to restart the real SSHD to test changes.
  • It prevents you from firewalling the administrative and VCS ports separately. I think most serious setups should not allow public-facing operational SSH access.
  • Although this isn't a concern in most cases, it prevents you from using a sshd with a ForceUser directive like we do in the cluster to get GitHub-like behavior where the user is ignored.

So (3) seems worse for less-sophisticated users (easier to make a serious mistake) and also worse for more-sophisticated users (they are more likely to want to separate operational and VCS access with network-level rules).

I'm OK with expanding the documentation to include (1) and (3) as options, but if we're recommending only one, I think (2) is still the best one to recommend.

This revision now requires changes to proceed.Jul 27 2015, 2:04 PM
tammymcguinness changed the visibility from "Public (No Login Required)" to "All Users".
epriestley changed the visibility from "All Users" to "Public (No Login Required)".Aug 26 2015, 1:40 AM