| Message ID | 20240307200830.221403-1-emil.kronborg@protonmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | openssh: enable sshd.service by default | expand |
On 7 Mar 2024, at 20:08, Emil Kronborg via lists.openembedded.org <emil.kronborg=protonmail.com@lists.openembedded.org> wrote: > > Socket activation is prone to DoS (denial of service) because too many > connections will permanently deactivate sshd.socket [1]. Also, since > socket units do not allow setting Restart, accepting new connections can > fail due to, for example, OOM (out of memory) [2]. Therefore, it seems > more sensible to use sshd.service by default and let sshd.socket be an > optional choice. Counter-argument: this is why it’s a PACKAGECONFIG, and socket activation has the advantage that it makes boots faster. If DoS is a concern, then the distro can switch trivially to service activated. Ross
On Fri, Mar 15, 2024 at 16:09 +0000, Ross Burton wrote: > On 7 Mar 2024, at 20:08, Emil Kronborg via lists.openembedded.org <emil.kronborg=protonmail.com@lists.openembedded.org> wrote: > > > > Socket activation is prone to DoS (denial of service) because too many > > connections will permanently deactivate sshd.socket [1]. Also, since > > socket units do not allow setting Restart, accepting new connections can > > fail due to, for example, OOM (out of memory) [2]. Therefore, it seems > > more sensible to use sshd.service by default and let sshd.socket be an > > optional choice. > > Counter-argument: this is why it’s a PACKAGECONFIG, and socket activation has the advantage that it makes boots faster. If DoS is a concern, then the distro can switch trivially to service activated. > > Ross Those are fair arguments. What do you think about the situation where sshd.socket becomes disabled, and you are unable to connect? I can see this being a problem for remote boards or boards that are not easily accessible. FWIW, socket activation is disabled by default on Arch Linux and Fedora. I don't have a box running Debian (or any other distros) right now to check those as well.
diff --git a/meta/recipes-connectivity/openssh/openssh_9.6p1.bb b/meta/recipes-connectivity/openssh/openssh_9.6p1.bb index 1fd36a266fde..a21570ed9382 100644 --- a/meta/recipes-connectivity/openssh/openssh_9.6p1.bb +++ b/meta/recipes-connectivity/openssh/openssh_9.6p1.bb @@ -57,7 +57,7 @@ DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d) # systemd-sshd-socket-mode means installing sshd.socket # and systemd-sshd-service-mode corresponding to sshd.service -PACKAGECONFIG ??= "systemd-sshd-socket-mode" +PACKAGECONFIG ??= "systemd-sshd-service-mode" PACKAGECONFIG[kerberos] = "--with-kerberos5,--without-kerberos5,krb5" PACKAGECONFIG[ldns] = "--with-ldns,--without-ldns,ldns" PACKAGECONFIG[libedit] = "--with-libedit,--without-libedit,libedit"
Socket activation is prone to DoS (denial of service) because too many connections will permanently deactivate sshd.socket [1]. Also, since socket units do not allow setting Restart, accepting new connections can fail due to, for example, OOM (out of memory) [2]. Therefore, it seems more sensible to use sshd.service by default and let sshd.socket be an optional choice. [1] https://bugs.archlinux.org/task/62248 [2] https://github.com/systemd/systemd/issues/11553 Signed-off-by: Emil Kronborg <emil.kronborg@protonmail.com> --- meta/recipes-connectivity/openssh/openssh_9.6p1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)