systemd script for sshd allows it to start too early should wait for authentication services...

[Jonathan Gutow]

After the most recent update to 16.04 I found that sshd failed to launch on bootup. On my particular system this is because it was not able to authenticate the user 'sshd'. It appears to be because it is starting before authentication services are completely available on my system. A simple fix was to make the following change to /lib/systemd/system/ssh.service:

--After=network.target auditd.service
++After=network.target auditd.service accounts-daemon.service

Starting too early might be a security issue, but I do not have the expertise to make that judgment. This may also be related to and solve this bug #1024475 as I am also serving some of my accounts from ldap.

[Christian Ehrhardt  (paelzer)]

Hi Jonathan,
shouldn't that be an ssh bug then?

Was there any reason to flag cloud-init - maybe you used cloud-init to set that up?

[Andreas Hasenack (ahasenack)]

Can you share your nss_ldap configuration, as well as /var/log/syslog and /var/log/auth.log? And, just to confirm, your sshd user is NOT in ldap, right?

[Jonathan Gutow (gutow)]

1. I did not intend to set it up as cloud-init. I assumed it got flagged because I tagged it with systemd-boot. Sorry if that messed things up. I'm not even sure what packages cloud-init covers. If it is not appropriate, it should be deleted.

2. The system this resides on is part of a cluster used for quantum computations. It is usually isolated from the networks. With minimum luck I will have time to transfer over the nss_ldap config and the requested logs today. However, your last question suggests what is probably the issue. I did not intentionally move sshd to ldap, but when this problem occurred I found that that is where it now resides. I am quite suspicious that is the actual problem. The other nodes on my system have a local sshd user. They are still running 14.0.4 rather than 16.04. The node I am having issues with is not used for computations, so gets used for initial upgrade testing.

[Colin Watson (cjwatson)]

Right, sshd really must be a local user, so if it's currently in LDAP then that would indeed be the problem.

I don't think this is a bug in openssh, so I'm marking this Invalid for now, but feel free to reopen if new information arises.

[Jonathan Gutow (gutow)]

I recreated the sshd account locally on the machine and it now starts the sshd daemon correctly using the default ssh.service file. I am withdrawing this bug report. If I see the sshd account disappear again, I will open another bug report on that.