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.
See also: - https://github.com/coreos/bugs/issues/966 - https://github.com/coreos/bugs/issues/2181
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.