Package: openssh-server Version: 1:7.4p1-9 Severity: important Hi,
the sshd process still puts the privilege separation directory in /var/run/sshd. Since /var/run is symlinked to /run, this is fine in the vast majority of cases. However, in rare cases where /var is on a dedicated filesystem, it might be the case that /var is not yet fully mounted when sshd is started. Moving the privilege separation directory to /run fixes this issue at least for ssh, which is important since one is able to fix other things on the system once one is able to log in. I therefore believe that this trivial change should be in stretch. Long version (including a bit of systemd ranting, excuse me for that): (1) Before systemd, an early init script would issue a mount -a call which in turn mounted all file systems marked auto in /etc/fstab and only returned when all possible mounts completed. A failed mount of a single file system resulted in a failed mount but allowed the boot to continue, which frequently resulted in a crippled system, but one that could be logged into even from remote to fix things. (2) systemd's default behavior is to stop the boot process once a single filesystem fails to mount, which needs (a) access to the console of the system which might be time-consuming and expensive in the case of a headless server in a datacenter and (b) the root password to fix things, which might be hard to obtain. A lot of companies keep the root passwords of the servers in a safe or divided between two people, one of them at manager level, which need to be called up to get access to the root password. In those situations, root access for the admins is usually obtained with sudo after a normal login. Therefore, needing the root password to handle a thing as simple as a failed mount is bad. (3) If the "nofail" option is set on the fstab entry, the hard dependency of local-fs.target to, for example, var.mount is relaxed. While this is frequently mistaken as what an admin wanting to get (1) behavior back wants, it actually does make the system not even wait for the mount to complete before the boot continues. In the /var case, this leads to systemd-tmpfiles-setup.service creating /var/run/sshd on the mount point, which is over-mounted by the actual /var a second later, which in turn has the /var/run => /run symlink with /run/sshd missing, resulting in a systemd that cannot be logged in to because sshd is missing its privilege separation directory. Since there is currently no way to take a decision other than (2) or (3) short of moving /var to the root file system, ssh should be using /run instead of /var/run in the first place. Thanks for considering. Greetings Marc
