Re: sshd package systemd misconfiguration?
On Thu, Sep 15, 2022 at 12:02:21PM +0200, Michael wrote:
> i recently had problems to reach some of my host with ssh. as it turned out,
> it was b/c sshd refused the connection due to a missing /run/sshd directory.
>
> the logfile entry:
> Aug 28 00:10:08 mail sshd[151893]: fatal: Missing privilege separation
> directory: /run/sshd
>
> so i started digging, and to my surprise i found out that on the affected
> servers sshd was configured to be invoked by ssh.socket (via ssh@.service
> with the -i option), wheras on all other hosts sshd was running as a daemon
> (via ssh.service whith the -D option).
>
> so, my first question is: why?
I'm afraid only you can answer that one.
> now that i know the problem, i have essentially three choices (assuming not
> to change the invocation via ssh.socket):
> 1: create /run/sshd whenever it disappears
> 2: prevent /run/sshd from being deleted
> 3: make each ssh@.service session use its own directory
It's supposed to be created as needed. There should be two lines in
the unit file:
unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh@.service
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh.service
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
That should cause the /run/sshd directory to be created when the service
is started, and removed when it's stopped.
It's possible that someone has created a local override file on your
system which suppresses this, or that someone has actually edited the
unit file in /lib. The latter should never happen, as a package upgrade
will replace the file and destroy the edits.
If the former has happened, you should see ssh.* files or directories
under /etc/systemd/system/. If you have anything there which isn't
a symlink named sshd.service pointing to /lib/systemd/system/ssh.service
please show it to us -- "ls -l" output on the file, plus the file's
contents.
If your /lib/systemd/system/ssh@.service doesn't contain the two lines
I showed, then you might start by reinstalling the package, or perhaps
by noting the timestamp on the file, which should tell you when it was
modified. Perhaps that will jog your memory about someone who might
have changed it. Or maybe the file is simply corrupted by file system
damage, which should be obvious in a text editor.
Reply to: