Comment 6 for bug 1991592

Revision history for this message
Robie Basak (racb) wrote : Re: [Bug 1991592] Re: openssh-server should ship a systemd generator to generate ssh socket port configuration from sshd_config

On Thu, Oct 06, 2022 at 01:04:05PM -0000, Corey Reichle wrote:
> If the point is to increase density, then sshd should just be off, and
> not automatically started, unless it's required for work.

Socket activation provides a smoother (runtime) UX for users, and is
well established as a mechanism to reduce runtime footprint without any
impact to users who want to use the service. Why do you think it's
preferable to have the daemon not started and without socket activation?

> If ssh is selected at install time, to be installed, and listening, then
> the user expectation is that it is installed, and listening. Not just
> "listening as needed".

Why? What user story is broken by socket activation here?

> Or, conversely, as I proposed in the original ticket (That somehow got
> marked as a duplicate of this ticket, that was created later): Migrate
> all configuration for openssh-server out of /etc/ssh/sshd_config, and
> into it's unit file.

I'm pretty sure this would result in far more pushback from the
community than merely enabling socket activation. We'd end up with an
order of magnitude more upgrade path issues in doing this, and we'd be
diverging from the entire rest of the community.

> No, there isn't generally an expectation that you will require two
> wholly unconnected places to be configured for something that is only
> configured in one place for every other distro, and every other OS that
> openssh-server runs on.

It's increasingly common to use socket activation on systemd-based
distros. Ubuntu may be pushing ahead on the sshd side, but socket
activation in general is already in place in various other packages.

I accept that the "two different places" configuration issue arises as a
consequence of socket activation, and this is poor UX. But the general
concept already exists in other areas (eg. After=network-online.service,
and AppArmor), and doing otherwise in the general case would require a
reversal, or even a "ban", on the use of socket activation across all
packages in Ubuntu. I don't think that makes sense, but even if it did,
it'd have to be a bigger discussion than just in this bug. As long as
socket activation is a generally acceptable pattern in Ubuntu, I see no
reason why sshd would be expected to be special and not use it.