> Socket activation provides a smoother (runtime) UX for users SSHD configuration is not a user issue, but a systems administration issue. A smoother UX for system administrators is a) Fully documented solutions, or b) One source of truth for all things regarding a service, hence the push for infrastructure as code - The repo is the one source of truth for the service.
> Why do you think it's preferable to have the daemon not started and without socket activation? Because, when a systems administrator, or devops person decides to enable SSH listening... they expect ssh to be listening. And they both expect the documented configuration of openssh to be standard across everywhere openssh-server is installed. > Why? What user story is broken by socket activation here? The user story that prompted this ticket: I configured ssh to listen on one family, and one address, with another service listening on 22 on another address, for both families. Regardless of my nginx configuration and my openssh-server configuration, unbeknownst to me... a socket file was dropped for openssh-server, making nginx failing to start, because it could not bind to the required ports. Nowhere was it documented that sshd now needs two configuration files, just to tell it to listen on a port, and address it was already told to do. openssh-server when started didn't mention that it's configure on a port, that requires a socket. And my only way to intuit it was to find init listening on 22 for some god awful reason. > I'm pretty sure this would result in far more pushback from the community than merely enabling socket activation. Are we sure about this? Pretty certain the push to systemd for the linux world, would make it pretty easy to figure out the configuration is now in a unit file, where it should be anyways. Just like how people now know that /etc/network/interfaces it not the place to configure the network now, but rather /etc/netplan/*.yaml. Its documented, and the way. > 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. This design choice already diverges from the rest of the community. This is the only distro where a very common service has undocumented methods of configuring ports. It's almost like there's a push to re- create inetd here, without making the required changes to use such a supervisor service. > or even a "ban", on the use of socket activation across all packages in Ubuntu I'm not proposing a ban on socket activation, even for this package. Just one place to configure the service, not two, or three. > 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. If Ubuntu is going the route of multiple places to configure everything, then perhaps the problem is me, and I need to search for another solution over Ubuntu. Because two and three sources of truth is not optimal, especially when undocumented, at all. Regardless of an "accepted pattern". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1991592 Title: openssh-server should ship a systemd generator to generate ssh socket port configuration from sshd_config Status in openssh package in Ubuntu: Triaged Bug description: A criticism of the existing sshd socket activation implementation is that Port/ListenAddress options are migrated on a one-time basis at package upgrade time, and afterwards users get the surprising behavior that Port/ListenAddress settings added to sshd_config are ignored. A systemd generator could be used to change the ssh socket unit configuration on boot, and on each change of /etc/ssh/sshd_config. Sample implementation from Dimitri: ssh.socket: [Unit] Wants=sshd-config.path # # Note the below defaults are cleared and overriden by # /lib/systemd/system-generators/sshd-generator # based on the sshd config from the sshd -T output # ListenStream=[::]:22 ListenStream=0.0.0.0:22 diff --git a/systemd/sshd-config.path b/systemd/sshd-config.path new file mode 100644 index 000000000..cfa9674a3 --- /dev/null +++ b/systemd/sshd-config.path @@ -0,0 +1,4 @@ +[Unit] +ConditionPathExists=!/etc/ssh/sshd_not_to_be_run +[Path] +PathChanged=/etc/ssh/sshd_config diff --git a/systemd/sshd-config.service b/systemd/sshd-config.service new file mode 100644 index 000000000..b009ea52c --- /dev/null +++ b/systemd/sshd-config.service @@ -0,0 +1,5 @@ +[Unit] +Description=Regenerate ssh.socket.d/ssh-listen.conf drop-in + +[Service] +ExecStart=/bin/systemctl daemon-reload diff --git a/systemd/sshd-generator b/systemd/sshd-generator new file mode 100755 index 000000000..72c6aac04 --- /dev/null +++ b/systemd/sshd-generator @@ -0,0 +1,10 @@ +#!/bin/sh +set -eu +mkdir -p /run/sshd +sshd -t +mkdir -p $1/ssh.socket.d +target="$1/ssh.socket.d/ssh-listen.conf" +echo '[Socket]' > $target +echo 'ListenStream=' >> $target +sshd -T | sed -n 's/^listenaddress /ListenStream=/p' >> $target +rmdir --ignore-fail-on-non-empty /run/sshd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1991592/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
