Need Advice about MaxConnections on ssh.socket

[Marc Haber <mh+systemd-devel@xxxxxxxxxxxx>]

Hi,

I am using ssh.socket to invoke ssh servers. What is not running cannot
fail:

[Unit]
Description=OpenBSD Secure Shell server socket
Before=ssh.service
Conflicts=ssh.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

One of my systems is rather frequently target of scans, which the socket
unit doesn't like. Here an excerpt from the log:

Feb 11 02:42:40 gancho systemd[1]: Started OpenBSD Secure Shell server per-connection daemon (221.229.220.180:38738).
Feb 11 02:42:42 gancho systemd[1]: ssh@10262-85.214.162.66:22-221.229.220.180:38738.service: Succeeded.
Feb 11 02:42:52 gancho systemd[1]: ssh.socket: Too many incoming connections (64), dropping connection.
(repeat 135 (sic!) times)
Feb 11 02:42:52 gancho systemd[1]: ssh.socket: Trigger limit hit, refusing further activation.
Feb 11 02:42:52 gancho systemd[1]: ssh.socket: Failed with result 'trigger-limit-hit'.
Feb 11 02:42:52 gancho systemd[1]: Started OpenBSD Secure Shell server per-connection daemon (2.57.122.26:56488).
(repeat 63 times)
Feb 11 02:42:53 gancho systemd[1]: ssh@10285-85.214.162.66:22-2.57.122.26:56106.service: Succeeded.
(repeat 63 times)

The machine is one of my older boxes, running Debian oldoldstable with
systemd 241. I have cross-checked systemd.socket(5) with more recent
systemd versions, and the rate limiting configuration with
MaxConnections= isn't documented differently in current systemd
versions. I see the same issue on systems running a recent systemd
version as well.

MaxConnections=: The maximum number of connections to simultaneously run
services instances for, when Accept=yes is set. If more concurrent
connections are coming in, they will be refused until at least one
existing connection is terminated. This setting has no effect on sockets
configured with Accept=no or datagram sockets. Defaults to 64.

Actual behavior looks a bit different: Once the socket unit has failed
with "trigger-limit-hit", the socket doesn't listen any more and manual
intervention is needed, restarting the socket unit, before one is able
to log in again. In this case, this was possible since the machine has
LOM, but not all my machines have that.

Am I reading the documentation wrong? If I understand the manpage
correctly, the issue is supposed to reset itself and the socket is
supposed to listen again. That does not seem to be the case, I think the
ssh.socket unit is into a permanently failed state.

Can systemd be configured to reset the unit automatically after, for
example, two hours? I'd rather not have a dedicated timer unit to reset
the socket every second hour.

I would love to hear your opinion.

Greetings
Marc


-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421