Re: [EXT] Need Advice about MaxConnections on ssh.socket

["Windl, Ulrich" <u.windl@xxxxxx>]

I had similar effects (even though not parallel) from pre-systemd times. As most of those attempts were coming from a specific IP, I added some firewall rule, and it calmed down things significantly. Maybe today one could add such firewall rules automatically and dynamically from detected attacks I guess.

Or maybe even redirect to some honey pot, saying "Congratulations, you succeeded to hack this system, now go away!"

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On
> Behalf Of Marc Haber
> Sent: Tuesday, February 11, 2025 4:26 PM
> To: Systemd <systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
> Subject: [EXT]  Need Advice about MaxConnections on
> ssh.socket
> 
> 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