Bug 2025716
Summary: | Consider dropping sshd.socket unit | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Timothée Ravier <travier> |
Component: | openssh | Assignee: | Timothée Ravier <travier> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | crypto-team, dbelyavs, dwalsh, jjelen, lkundrak, mattias.ellert, mzeuom, ppisar, tm |
Target Milestone: | --- | Keywords: | Reopened, Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | openssh-9.3p1-8.fc39 openssh-9.3p1-10.fc40 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-08-03 11:06:03 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Timothée Ravier
2021-11-22 19:38:12 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36. I'm sorry, I'm not going to fix this issue. 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. 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. 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. Re-opening so that I can use this bug for tracking. This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38. FEDORA-2023-64f8335634 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-64f8335634 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. 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. Yes, I'm aware of MaxStartups though I think it was added earlier than in 9.3 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. 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. This likely has implication for the F39 update in Fedora CoreOS so I filed: https://github.com/coreos/fedora-coreos-tracker/issues/1558 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 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 FEDORA-2023-f37207c016 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f37207c016 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. |