[Pkg-systemd-maintainers] systemd support in openssh-server

[Colin Watson]

On Tue, Feb 11, 2014 at 12:32:34AM +0100, Michael Biebl wrote:
> I noticed that you added systemd .service files in openssh 1:6.5p1-1.
> Thanks a lot for that!
> There are a few issues though that I noticed which I'd like to discuss.
> 
> SSH supports two modes:
> 
> a/ The traditional way of being started via ssh.service, which starts
> the service on boot via multi-user.target (basically what the SysV init
> script does, daemon mode)
> b/ On-demand starting via socket activation using: ssh.socket +
> ssh at .service.
> This will only setup the socket file defined in ssh.socket and start
> sshd on demand on incoming requests. (inetd mode)
> 
> I think it makes sense to keep using the traditional setup i.e. a/ and
> if an administrator wants mode b/ it should be enabled explicilty (and
> ssh.service disabled).

I agree, particularly because the socket mode doesn't necessarily
interact well with some of sshd's options.

> But the package both enables ssh.socket and ssh.service (in postinst),
> which is kinda odd.

This is an oversight.  Thanks for letting me know - I'll stop
dh_systemd_enable from doing this in 1:6.5p1-2, and write some postinst
code to clean up the mistake.

> Do you think it would be helpful if we write a small paragraph in
> README.Debian explaining the two different modes and how to enable/use them?

I already did. :-)

  systemd socket activation
  -------------------------
  
  If you want to reconfigure systemd to launch sshd using socket activation,
  then you can run:
  
    systemctl stop ssh.service
    systemctl start ssh.socket
  
  To make this permanent:
  
    systemctl disable ssh.service
    systemctl enable ssh.socket
  
  This may be appropriate in environments where minimal footprint is critical
  (e.g. cloud guests).  Be aware that this bypasses MaxStartups, and systemd's
  MaxConnections cannot quite replace this as it cannot distinguish between
  authenticated and unauthenticated connections; see
  https://bugzilla.redhat.com/show_bug.cgi?id=963268 for more discussion.

> I also wonder why the following check was added:
> 
> ExecStartPre=/usr/bin/test -c /dev/null
> 
> Why is this needed? Seems rather odd to me. With devtmpfs being
> mandatory (in systemd/udev) nowadays, /dev/null is guaranteed to exist.
> Do you remember why this check was added? Afaics it doesn't seem
> necessary anymore nowadays.

Russ already provided a link to the original bug.  While I never tracked
down the exact script that was at fault for the users in question, as
it's very difficult to find retroactively, it can happen any time some
script accidentally does "rm /dev/null", at which point the next thing
to run as root and redirect to /dev/null will create it as a regular
file.  Nothing about systemd/udev prevents this from happening.  Yes,
this is absolutely somebody else's bug, and it seems to be pretty rare,
but when it happens I don't want to have to spend time dealing with the
bug reports.  A quick test call seems worth it.

Cheers,

-- 
Colin Watson                                       [cjwatson at debian.org]