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.