Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2025716 - Consider dropping sshd.socket unit
Summary: Consider dropping sshd.socket unit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Timothée Ravier
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-22 19:38 UTC by Timothée Ravier
Modified: 2023-09-15 11:07 UTC (History)
9 users (show)

Fixed In Version: openssh-9.3p1-8.fc39 openssh-9.3p1-10.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-03 11:06:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-336 0 None None None 2021-11-22 19:38:35 UTC

Description Timothée Ravier 2021-11-22 19:38:12 UTC
Description of problem:

Using the sshd.socket unit might lead to DoS in some cases and unexpected setups where some configuration options are silently ignored.

It has been dropped from Arch Linux for those reasons and we should consider removing it from Fedora.

See:
- https://wiki.archlinux.org/title/OpenSSH#Daemon_management
- https://bugs.archlinux.org/task/62248
- https://github.com/systemd/systemd/issues/11553

Version-Release number of selected component (if applicable):

Latest openssh-server package

How reproducible:

Always

Steps to Reproduce:
1. Using the sshd.socket unit
2. Use a configuration option ignored in this setup or be a victim of a DoS attack

Actual results:

Can not login via ssh or able to login from unwanted networks.

Expected results:

Can login via ssh and access is correctly limited to selected networks.

Comment 2 Ben Cotton 2022-02-08 21:22:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 3 Dmitry Belyavskiy 2022-09-08 12:45:10 UTC
I'm sorry, I'm not going to fix this issue.

Comment 4 Timothée Ravier 2022-10-19 15:33:56 UTC
Is it that you don't think we should fix it or that you don't have the time? I can make a PR if you're good taking it.

Comment 5 Dmitry Belyavskiy 2022-10-20 09:03:33 UTC
It's I don't think we should fix it. I don't understand this part well so not sure it's of much use.

Comment 6 Jakub Jelen 2022-10-20 09:48:18 UTC
I would just drop it. It was created when everything had to use systemd and everything had to be activated by socket to avoid running daemons, but it was never fully integrated and never working as expected so dropping the sshd.socket would make a lot of things easier. I do not think it is widely used. We had also counter-proposal to improve it in #1961785, but nobody stepped up to implement that so I think it is time to let it go.

Please, open a PR with this change. We would be happy to review and merge it.

Comment 7 Timothée Ravier 2023-02-06 17:24:41 UTC
Re-opening so that I can use this bug for tracking.

Comment 8 Ben Cotton 2023-02-07 15:12:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 9 Fedora Update System 2023-08-03 09:24:27 UTC
FEDORA-2023-64f8335634 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-64f8335634

Comment 10 Fedora Update System 2023-08-03 11:06:03 UTC
FEDORA-2023-64f8335634 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Petr Pisar 2023-08-04 08:02:32 UTC
Did you know that recent openssh (9.3?) added MaxStartups with a default value having a similar DoS effect? The default settings causes random dropping of new connection if there are already 10 unauthenticated connections. I had to increase that option on my system, because 10 was impractically low when the system was under a moderate attack and denied me from accessing the host from my internal network.

Comment 12 Dmitry Belyavskiy 2023-08-04 08:23:25 UTC
Yes, I'm aware of MaxStartups though I think it was added earlier than in 9.3

Comment 13 Lennart Poettering 2023-08-07 09:48:35 UTC
huh, if you don't want the trigger limit, disable it. don't kill the socket unit. Already for compat with previous releases: people have the socket unit enabled.

See https://www.freedesktop.org/software/systemd/man/systemd.socket.html#TriggerLimitIntervalSec= for details.

Comment 14 Timothée Ravier 2023-08-30 14:21:39 UTC
This is apparently also useful when you run a lot of containers/LXCs with ssh daemons and want to save on memory. From https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189.

MaxStartups (from https://man7.org/linux/man-pages/man5/sshd_config.5.html) is different in that it won't make the sshd completly stop accepting connections for ever, only for a limited period of time, compared to the failed sshd.socket case.

Initially, I did not know that we could disable that behavior with `TriggerLimitIntervalSec=` which is why I suggested removing the unit. But with that option, maybe keeping the unit with a warning makes sense.

There are however other related issues still not resolved:
- https://github.com/systemd/systemd/issues/19650
- which comes from https://bugzilla.redhat.com/show_bug.cgi?id=1851478#c19
- which triggered https://bugzilla.redhat.com/show_bug.cgi?id=1961785

Change for this bug was made in https://src.fedoraproject.org/rpms/openssh/c/8a294387d01967d610543b05d9b5078cea8a6543?branch=rawhide

Not sure what's the best path here. The socket as it exists right now has issues that the service does not have. Unfortunately removing it without a contingency / migration plan for users that were using it is likely to create surprises.

Maybe it should have been a Fedora Change to raise awareness. Sorry I created the issue initially but did not correctly evaluate the potential impact.

Comment 15 Timothée Ravier 2023-08-30 14:31:50 UTC
This likely has implication for the F39 update in Fedora CoreOS so I filed: https://github.com/coreos/fedora-coreos-tracker/issues/1558

Comment 16 Timothée Ravier 2023-08-31 16:38:51 UTC
We think this change has bigger implications and should go through the change process. We filed a ticket with FESCO to discuss further: https://pagure.io/fesco/issue/3062

I understand the irony of the situation as I'm the original reporter that asked for this change and I'm now arguing for it to be delayed/reverted.

The main reasons that made me/us change our minds is that we now have more experience about major version upgrades in Fedora CoreOS and that the functionality suggested to "workaround/fix" the original issues did not exist at the time in systemd:
- https://github.com/systemd/systemd/blob/main/NEWS#L3564
- https://github.com/systemd/systemd/blob/main/NEWS#L3992

Comment 17 Timothée Ravier 2023-09-11 15:42:28 UTC
For the record, this has been reverted in F39 (https://pagure.io/fesco/issue/3062) and is proposed for F40 in https://fedoraproject.org/wiki/Changes/Drop_Sshd_Socket

Comment 18 Fedora Update System 2023-09-15 09:17:23 UTC
FEDORA-2023-f37207c016 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f37207c016

Comment 19 Fedora Update System 2023-09-15 11:07:43 UTC
FEDORA-2023-f37207c016 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.