Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Olivier Allard-Jacquin]

Hi,

I'm running sshd trough xinetd, with following configuration:

$ cat /etc/xinetd.d/sshd
service ssh
{
id  = sshd
disable = no
type= UNLISTED
port= 22
socket_type = stream
wait= no
user= root
server  = /usr/sbin/sshd
server_args = -i -4
log_on_success  += DURATION USERID
log_on_failure  += USERID
nice= 10
only_from   = x.x.x.x/24
}

So, in order for system to not start /lib/systemd/system/ssh* , I've
create a blank :
/etc/ssh/sshd_not_to_be_run

Until now (before "openssh-server:amd64 1:7.5p1-5"), in order for this
configuration to work, I've add to my "/etc/rc.local" a :

# SSHD fix
[ ! -d /var/run/sshd/ ] && (mkdir -p /var/run/sshd/)

But now, with "1:7.5p1-10" upgrade, I've to modify "/etc/rc.local" to :

# SSHD fix
[ ! -d /run/sshd/ ] && (mkdir -p /run/sshd/)

Best regards,

Olivier

-- 
~~~  _/\_  ~~~
Phoenix /   _ \/ _   \Olivier Allard-Jacquin
   /   / \  / \   \   Web:  http://olivieraj.free.fr/
  /___/  /  \  \___\  Mail: olivie...@free.fr
 /  ///\\\  \ ~~~ Linux Powered !!

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[doak]

Please consider to ensure that the SSH privilege-seperation directory is in 
place as long as SSH is installed (in contract to "as long as SSH is running').

Rationale:

>> RuntimeDirectory=sshd
>> Perhaps that would be a reliable way to fix the problem...
> That does indeed seem like a plausible approach.  Committed to git
> master, thanks.

Although this seems to be very robust way to ensure the privilege-separation 
directory exists and is empty, it disallows to run 'sshd' as a non-root user 
because of missing '/run/sshd' if 'sshd' has not been started by 'systemd'.
My use case is to establish a tunnel between two clients without the need of 
root privileges. The (potentially) missing '/run/sshd' prevents this.

I am not a security expert and do not know if this use case implies security 
issues (e.g. breaks privilege separation), but security is at least not 
decreased if '/run/sshd' exists even if 'sshd' is not running: A user is able 
to create a patched copy of 'sshd' replacing '/run/sshd' with '/tmp/sshd' and 
create a symlink from '/tmp/sshd' to any directory owned by root which is not 
accessible to group or world-side (like e.g. '/run/log').
In fact, users will compromise system security if they are tempted to 
workaround missing '/run/sshd' this.


With best regards,
doak


On Sun, 23 Jul 2017 13:15:45 +0100 Colin Watson  wrote:
> Control: tag -1 pending
> 
> On Mon, Jul 17, 2017 at 09:26:26AM +1000, Dmitry Smirnov wrote:
> > So I had a chance to try another fix to the problem: I was able to start
> > "ssh.service" again after adding the following line:
> > 
> > RuntimeDirectory=sshd
> > 
> > Perhaps that would be a reliable way to fix the problem...
> 
> That does indeed seem like a plausible approach.  Committed to git
> master, thanks.
> 
> -- 
> Colin Watson   [cjwat...@debian.org]
> 
> 

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Colin Watson]

Control: tag -1 pending

On Mon, Jul 17, 2017 at 09:26:26AM +1000, Dmitry Smirnov wrote:
> So I had a chance to try another fix to the problem: I was able to start
> "ssh.service" again after adding the following line:
> 
> RuntimeDirectory=sshd
> 
> Perhaps that would be a reliable way to fix the problem...

That does indeed seem like a plausible approach.  Committed to git
master, thanks.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Dmitry Smirnov]

On Monday, 5 June 2017 9:38:13 AM AEST Colin Watson wrote:
> Would you like to look into why that didn't work on your system?

Probably due to failure of (non essential) mount point or unrelated service...

It happened again today:


Jul 17 09:14:00 deblab systemd[1]: Starting OpenBSD Secure Shell server...
Jul 17 09:14:00 deblab sshd[153531]: Missing privilege separation directory: 
/run/sshd
Jul 17 09:14:00 deblab systemd[1]: ssh.service: Main process exited, 
code=exited, status=255/n/a
Jul 17 09:14:00 deblab systemd[1]: Failed to start OpenBSD Secure Shell server.
Jul 17 09:14:00 deblab systemd[1]: ssh.service: Unit entered failed state.
Jul 17 09:14:00 deblab systemd[1]: ssh.service: Failed with result 'exit-code'.


So I had a chance to try another fix to the problem: I was able to start
"ssh.service" again after adding the following line:

RuntimeDirectory=sshd

Perhaps that would be a reliable way to fix the problem...

See [1] for details.

[1]: 
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=

-- 
Regards,
 Dmitry Smirnov.


signature.asc
Description: This is a digitally signed message part.

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Russ Allbery]

Dmitry Smirnov  writes:

> Interesting... Why not use Debhelper to install the file? Historical
> reasons?  ;)

It's in /run, which is ephemeral and destroyed on each reboot, and
maintainer scripts created by debhelper (and directories shipped in the
package) are only created once during package installation.

-- 
Russ Allbery (r...@debian.org)   

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Dmitry Smirnov]

On Monday, 5 June 2017 9:38:13 AM AEST Colin Watson wrote:
> It's already there!  It's in a slightly different place in the source
> package for historical reasons, but you'll find it in
> debian/systemd/ssh.conf with the exact contents as you suggest above,
> and it's installed in /usr/lib/tmpfiles.d/sshd.conf.

Interesting... Why not use Debhelper to install the file? Historical reasons? 
;)

 > Would you like to look into why that didn't work on your system?

I wish I knew why it did not work... :(
File is indeed there...

-- 
Cheers,
 Dmitry Smirnov.

---

To predict the behavior of ordinary people in advance, you only have to
assume that they will always try to escape a disagreeable situation with
the smallest possible expenditure of intelligence.
-- Friedrich Nietzsche


signature.asc
Description: This is a digitally signed message part.

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Colin Watson]

On Mon, Jun 05, 2017 at 01:28:58PM +1000, Dmitry Smirnov wrote:
> To fix this problem _properly_ the following file should be introduced:
> 
> debian/openssh-server.ssh.tmpfile
> 
> with the following content:
> 
> 
> d /run/sshd 0755 root root
> 

It's already there!  It's in a slightly different place in the source
package for historical reasons, but you'll find it in
debian/systemd/ssh.conf with the exact contents as you suggest above,
and it's installed in /usr/lib/tmpfiles.d/sshd.conf.

Would you like to look into why that didn't work on your system?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#864190: openssh-server: Missing privilege separation directory: /run/sshd

[Dmitry Smirnov]

Package: openssh-server
Version: 1:7.4p1-10
Severity: important

Reported this problem in the past as #823659 with patch yet it is still
not fixed as I run into the very same issue once again... :(

sshd.service did not start after reboot due to missing "/run/sshd"
directory:


Missing privilege separation directory: /run/sshd


I was able to start sshd after the following command:


sudo mkdir /run/sshd

To fix this problem _properly_ the following file should be introduced:

debian/openssh-server.ssh.tmpfile

with the following content:


d /run/sshd 0755 root root


-- 


The information contained in this email and any attached files are strictly 
private and confidential. This email should be read only by the intended 
addressee only. If the recipient of this message is not the intended addressee, 
please call Staples Australia Pty Limited on +61 2 9335 0555 or Staples New 
Zealand Limited on +64 9 271 7600 and promptly delete this email and any 
attachments. The intended recipient of this email may only use, reproduce, 
disclose or distribute the information contained in this email and any attached 
files with the prior written permission of StaplesTM. If you are not the 
intended addressee, you are strictly prohibited from using, reproducing, 
disclosing or distributing the information contained in this email and any 
attached files. StaplesTM advises that this email and any attached files should 
be scanned to detect viruses. StaplesTM accepts no liability for loss or damage 
(whether caused by negligence or not) resulting from the use of any attache!
 d files.