Re: Query on sshd.socket sshd.service approaches

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 06.03.24 11:11, Shreenidhi Shedi (shreenidhi.shedi@xxxxxxxxxxxx) wrote:

> Hi All,
>
> What is the rationale behind using sshd.socket other than not keeping sshd
> daemon running always and reducing memory consumption?

Note that there are two distinct modes to running sshd via socket
activation: the per-connection mode (using sshd's native inetd mode),
where there's a separate instance forked off by systemd for each
connection, and the a mode where systemd just binds the socket, but
it's served by a single instance. The latter is only supported via an
out-of-tree patch afaik though, which at least debian/ubuntu ship:

https://salsa.debian.org/ssh-team/openssh/-/commit/7fa10262be3c7d9fd2fca9c9710ac4ef3f788b08

Unless you have a gazillion of connections coming in every second I'd
probably just use the per-connection inetd mode, simply because it's
supported upstream. Would be great of course if openssh would just add
support for the single-instance mode in upstream too, but as I
understand ssh upstream is a bit special, and doesn't want to play
ball on this.

To summarize the benefits of each mode:

1. Traditional mode (i.e. no socket activation)
   + connections are served immediately, minimal latency during
     connection setup
   - takes up resources all the time, even if not used

2. Per-connection socket activation mode
   + takes up almost no resources when not used
   + zero state shared between connections
   + robust updates: socket stays connectible throughout updates
   + robust towards failures in sshd: the bad instance dies, but sshd
     stays connectible in general
   + resource accounting/enforcement separate for each connection
   - slightly bigger latency for each connection coming in
   - slightly more resources being used if many connections are
     established in parallel, since each will get a whole sshd
     instance of its own.

3. Single-instance socket activation mode
   + takes up almost no resources when not used
   + robust updates: socket stays connectible throughout updates

> With sshd.socket, systemd does a fork/exec on each connection which is
> expensive and with the sshd.service approach server will just connect with
> the client which is less expensive and faster compared to
> sshd.socket.

The question of course is how many SSH instances you serve every
minute. My educated guess is that most SSH installations have a use
pattern that's more on the "sporadic use" side of things. There are
certainly heavy use scenarios though (e.g. let's say you are github
and server git via sshd). I'd suggests to distros to default to mode
2, and alternatively support mode 3 if possible (and mode 1 if they
don#t want to patch the support for mode 3 in)

> And if there are issues in unit files like in
> https://github.com/systemd/systemd/issues/29897 it will make the system
> unusable.

Did any distro ship a unit file like that? That was clearly a buggy
(local?) unit file, I am not aware of any big distro shipping such a
unit file.

Lennart

--
Lennart Poettering, Berlin