sshd does not start after update on non-Ubuntu kernels where fchownat() is broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openssh (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
[Triage Notes]
This issue is caused on Ubuntu derivatives due to problematic symlink handling on those systems. See bug 1804847 for details, and comment 10 below for details and a workaround.
Proper Ubuntu systems do not appear to be affected.
[Original Description]
After processing system update by:
apt-get clean && apt-get autoclean && apt-get autoremove && apt-get update && apt-get upgrade && apt-get dist-upgrade && reboot
ssh server stops starting at system boot.
It starts after doing:
mkdir /var/run/sshd
chmod 0755 /var/run/sshd
service ssh start
It happens on fresh Ubuntu-16.04 installs on every VPS provide I have tested so far.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: openssh-server 1:7.2p2-4ubuntu2.6
Uname: Linux 2.6.32-042stab127.2 x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Thu Jan 31 10:18:56 2019
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: Missing privilege separation directory: /var/run/sshd
SourcePackage: openssh
UpgradeStatus: No upgrade log present (probably fresh install)
Hi,
I took a fresh system and it had openssh-server installed right away (as it is part of all the base images).
/var/run/sshd was at 0755 root:root already
I was wondering if the package install would kill the permission/ ownership, so I did
$ apt install --reinstall openssh-server
But things stayed fine.
Ok, then I purged the package and removed the path to then install it from scratch.
$ apt remove --purge openssh-server
$ rmdir /var/run/sshd
# ensured that /var/run/sshd really doesn't exist anymore
$ apt install openssh-server
The path is back and permissions are ok.
I can't find how you got into this situation :-/
I'm puzzled:
- from what to what do you upgrade trusty -> xenial or just a package version in xenial?
- do you have any idea where the bad permissions on /var/run/sshd might come in your case?
- if you follow my second example of purge, rmdir, install does the path get created correctly on your system?