On Fri, Sep 16, 2022 at 09:17:10AM +0200, Michael wrote:
> On Thursday, 15 September 2022 13:01:45 CEST, Greg Wooledge wrote:
> > unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh@.service
> > RuntimeDirectory=sshd
> > RuntimeDirectoryMode=0755
> with ssh@.service it is completely different. for each connection there is a
> dedicated sshd process being started, and each one of them has the same
> /run/sshd directory assigned. and that's the problem if you have more than
> one connection to a given host. as soon as the first connection is
> terminated, the /run/sshd directory disappears, and the other sshd's might
> run into problems.
OK then. This is a bit beyond my experience level, and should probably
be filed as a bug against Debian.
I did find this paragraph in systemd.exec(5):
Use RuntimeDirectory= to manage one or more runtime directories for
the unit and bind their lifetime to the daemon runtime. This is
particularly useful for unprivileged daemons that cannot create
runtime directories in /run/ due to lack of privileges, and to make
sure the runtime directory is cleaned up automatically after use.
For runtime directories that require more complex or different
configuration or lifetime guarantees, please consider using
tmpfiles.d(5).
Maybe you can find a workaround there, and/or contribute your workaround
when you file your bug report.
Personally, I've never configured sshd to use socket activation, nor do I
see any advantage in doing so. Back in the old days, we were always
warned *not* to do that, because the startup time could be extremely long
due to entropy exhaustion. Yeah, I know, entropy is handled differently
by the kernel now. Still, I don't see any reason to move away from the
tried-and-tested single daemon model.
