[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sshd package systemd misconfiguration?



On Fri 16 Sep 2022 at 09:17:10 (+0200), Michael wrote:
> On Thursday, 15 September 2022 13:01:45 CEST, Greg Wooledge wrote:
> 
> of course the first thing i did was to check if all the files from the
> package were as they should be, and everything was fine!
> 
> > 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
> 
> i never questioned that! my problem wasn't based on these lines are
> missing or in some way altered. my problem resulted in these lines
> being there as they are! ;)
> 
> > That should cause the /run/sshd directory to be created when the service
> > is started, and removed when it's stopped.
> 
> you got it! :)
> 
> having 'RuntimeDirectory=sshd' in ssh.service is totally fine! that
> is, b/c sshd runs as a daemon, and each new connection is handled by
> that exact daemon. so the /run/sshd directory stays there no matter
> how many connections to the host exist or being terminated, etc.
> 
> 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.

The rationale for having ssh@.service appears to be laid out in
https://bugzilla.redhat.com/show_bug.cgi?id=963268
and
http://0pointer.de/blog/projects/inetd.html
(not that I appreciate some of the points being made there).

> but i still don't understand, why this scenario prevents me from
> contacting a host with the formerly mentioned error message in the log
> file...

> > On Thu 15 Sep 2022 at 12:02:21 (+0200), Michael wrote:
> > > 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 don't think you've yet confirmed what's in your /etc/systemd tree
on the different hosts. Mine all show:

$ find /etc/systemd/ -name \*ssh\* -ls | squeeze-whitespace 
 1700765 0 lrwxrwxrwx 1 root root 31 Apr 16 20:31 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service
 1700799 0 lrwxrwxrwx 1 root root 31 Apr 16 20:31 /etc/systemd/system/multi-user.target.wants/ssh.service -> /lib/systemd/system/ssh.service
 1702117 0 lrwxrwxrwx 1 root root 42 Apr 16 20:56 /etc/systemd/user/sockets.target.wants/gpg-agent-ssh.socket -> /usr/lib/systemd/user/gpg-agent-ssh.socket
$ 

with no trace of the @ version, below.

$ diff -u /lib/systemd/system/ssh*service
--- /lib/systemd/system/ssh.service     2022-07-01 17:37:41.000000000 -0500
+++ /lib/systemd/system/ssh@.service    2022-07-01 17:37:41.000000000 -0500
@@ -1,22 +1,11 @@
 [Unit]
-Description=OpenBSD Secure Shell server
+Description=OpenBSD Secure Shell server per-connection daemon
 Documentation=man:sshd(8) man:sshd_config(5)
-After=network.target auditd.service
-ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
+After=auditd.service
 
 [Service]
 EnvironmentFile=-/etc/default/ssh
-ExecStartPre=/usr/sbin/sshd -t
-ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
-ExecReload=/usr/sbin/sshd -t
-ExecReload=/bin/kill -HUP $MAINPID
-KillMode=process
-Restart=on-failure
-RestartPreventExitStatus=255
-Type=notify
+ExecStart=-/usr/sbin/sshd -i $SSHD_OPTS           ←
+StandardInput=socket                              ←
 RuntimeDirectory=sshd
 RuntimeDirectoryMode=0755
-
-[Install]
-WantedBy=multi-user.target
-Alias=sshd.service
$ 

Cheers,
David.


Reply to: