Multiple sshd services cannot be executed

[Luke A. Perkins]

OpenSSH 7.6p1
Ubuntu 18.04.2 (LTS) (Bionic)

See also Ticket #1831765, #1690485, and #1832110 regarding the path of the privilege separation directory (aka: /run/sshd).

The current Debian installer sets the RuntimeDirectory=sshd (i.e. /run/sshd) in sshd.service (i.e. /lib/systemd/system/sshd.service) and sshd@.service (i.e. /lib/systemd/system/sshd@.service). This is not the best means of implementing this service. The problem is that the systemd deletes the RuntimeDirectory resource as soon as the service is stopped. When this happens, other sshd services will fault since the privileged separation directory is no longer there. We need to modify the configuration as follows:

1) Create /usr/lib/tmpfiles.d/sshd.conf that defines the /run/sshd directory with root:root as the owner and the protection of 0755.
2) Change the assignment of the RuntimeDirectory in sshd.service to something other than sshd (i.e. /run/sshd).
3) Change the assignment of the RuntimeDirectory in sshd@.service to something other than sshd (i.e. /run/sshd).

Both OpenSSH and Ubuntu have declined to provision a means of adjusting the Privilege Separation directory. Since both teams do not want to address this, we need to have a means of implementing multiple instance sshd invocation using systemd and avoiding using the RuntimeDirectory assignment of /run/sshd.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

It sounds like the actual bug you're reporting is:

> When this happens, other sshd services will fault since the privileged separation directory is no longer there.

Please could you provide exact steps to reproduce your "will fault" prediction? Once done, please change the bug status back to New. I'd appreciate the usual "steps to reproduce/expected behaviour/actual behaviour" clearly laid out please.

As this is an unusual end-user configuration, I'm marking Importance: Low based on our definitions at https://wiki.ubuntu.com/Bugs/Importance. Please note that this means that after you do reply and assuming that we do agree that the actual behaviour is a bug, I expect that a bug report to Debian will be required but no further action will take place in Ubuntu, save for the possibility of patches to stable releases if a fix does land in the development release via Debian and the patch meets our stable update requirements. I expect that if the fix is to sshd@.service then a local workaround will be trivially possible by overriding that service definition.

[Luke A. Perkins (public-a)]

The way I created this was to implement 2 sshd services called wan_sshd and lan_sshd. I used the existing sshd.service files as templates. See attached files. This solution reliably works using Ubuntu 18.04.2 LTS with OpenSSH 7.6p1.

Addition things I had to do:

1) Delete the sshd.service, sshd.socket, and sshd@.service in the /lib/systemd/system directory.
2) Perform a "sudo systemctl disable ssh". All this does is delete the links to the files in step #1.
3) Delete the /etc/rc*.d/S01ssh files.
4) Delete the /etc/init.d/ssh
5) Replace the /etc/default/ssh with the ssh.default in the ZIP file.
6) Delete the /etc/ssh/sshd_config. Add the sshd_*_config files from the ZIP file.
7) Add the wan_sshd* and lan_sshd* files to the /lib/systemd/system directory from the ZIP file. NOTE: Files called _at.service should be renamed to @.service.
8) Generate your own key files and make appropriate changes to the sshd_*_config files.
9) Add the usr_lib_tmpfiles_d.conf from the ZIP file as /usr/lib/tmpfiles.d/sshd.conf
10) Reboot the machine and make sure /run/sshd exists BEFORE enabling the 2 services.

I make the assumption that the reader has the skill set to use systemctl to get the services started. I also assume the reader has the skill set to edit a shsd_*_config file.

[Luke A. Perkins (public-a)]

NOTE: Even though this is listed as a low priority and an unusual configuration, the addition of /usr/lib/tmpfiles.d/sshd.conf and changing the RuntimeDirectory=sshd_service in the sshd.service file is a better solution that does not conflict with Upstream implementations.

[Robie Basak (racb)]

I'm sorry, your answer doesn't help complete this bug report, so I'm setting the status back to Incomplete.

You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the *problem* that you're describing.

In particular, I expect your report to first demonstrate the *problem*, not assume a solution. It will help if your problem statement includes the headings "Steps to reproduce", "Expected behaviour" and "Actual behaviour". Until you have done this I don't expect that your report will make any progress.

Once you've done that, please change the bug status back to New. Until you've done that, please leave the bug status as Incomplete.

[Launchpad Janitor (janitor)]

[Expired for openssh (Ubuntu) because there has been no activity for 60 days.]