Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[David Ťok]

On Sat, 19 Nov 2016 19:56:11 + Colin Watson  wrote:
> On Sat, Nov 19, 2016 at 12:46:57PM -0500, David Lee Lambert wrote:
> > Getting the same behavior on a fresh installation of Jessie (from the
> > netinst ISO). Every time I reboot, sshd doesn't restart until I either
> > `apt-get install --reinstall openssh-server` or `mkdir /var/run/sshd`.
> >
> > I've tried to add the second command to `/etc/rc.local`, but 
there's some

> > other error preventing that from running properly...
>
> A fresh install of jessie presumably uses systemd by default, so the
> last few entries in this bug log (especially the one from Russ
> immediately before yours) are probably relevant. The output of
> "systemctl status systemd-tmpfiles-setup.service" might be useful, or at
> least point you in the right direction.
>
> --
> Colin Watson [cjwat...@debian.org]


Hi,

  In my case - systemd didn't create /var/run/sshd when /var and /usr 
was different mountpoint than /. When i moved both folders to the same 
partition as / ssh started to work.


--
*COOLNET*
David Ťok
senior TMNT
Aut inveniam viam aut faciam
www.coolnet.cz 
david@coolnet.cz 

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[Colin Watson]

On Sat, Nov 19, 2016 at 12:46:57PM -0500, David Lee Lambert wrote:
> Getting the same behavior on a fresh installation of Jessie (from the
> netinst ISO). Every time I reboot, sshd doesn't restart until I either 
> `apt-get install --reinstall openssh-server` or `mkdir /var/run/sshd`.
> 
> I've tried to add the second command to `/etc/rc.local`, but there's some
> other error preventing that from running properly... 

A fresh install of jessie presumably uses systemd by default, so the
last few entries in this bug log (especially the one from Russ
immediately before yours) are probably relevant.  The output of
"systemctl status systemd-tmpfiles-setup.service" might be useful, or at
least point you in the right direction.

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

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[David Lee Lambert]

Package: openssh-server
Version: 1:6.7p1-5+deb8u3
Followup-For: Bug #645788

Getting the same behavior on a fresh installation of Jessie (from the
netinst ISO). Every time I reboot, sshd doesn't restart until I either 
`apt-get install --reinstall openssh-server` or `mkdir /var/run/sshd`.

I've tried to add the second command to `/etc/rc.local`, but there's some
other error preventing that from running properly... 

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  init-system-helpers1.22
ii  libc6  2.19-18+deb8u6
ii  libcomerr2 1.42.12-2
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
ii  libkrb5-3  1.12.1+dfsg-19+deb8u2
ii  libpam-modules 1.1.8-3.1+deb8u1+b1
ii  libpam-runtime 1.1.8-3.1+deb8u1
ii  libpam0g   1.1.8-3.1+deb8u1+b1
ii  libselinux12.3-2
ii  libssl1.0.01.0.1t-1+deb8u5
ii  libwrap0   7.6.q-25
ii  lsb-base   4.1+Debian13+nmu1
ii  openssh-client 1:6.7p1-5+deb8u3
ii  openssh-sftp-server1:6.7p1-5+deb8u3
ii  procps 2:3.3.9-9
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages openssh-server recommends:
ii  ncurses-term  5.9+20140913-1
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information:
  openssh-server/permit-root-login: false

Bug#645788: openssh-server: /run on tmpfs breaks sshd started, from inetd

[Paul Millar]

Hi Colin,

Apologies for hijacking this ticket with an unrelated problem.  You're 
quite correct in saying openssh-server package does the right thing.


For the record, my problem was (or appears to have been) triggered by a 
failure to mount an unrelated tmpfs file-system (/var/spool/cups/tmp) 
earlier in the boot sequence.  This failure was because /var/spool/cups 
was a symlink pointing to another partition.  If the other partition was 
not mounted when attempting to mount /var/spool/cups/tmp, the mount 
would fail.


Removing the /var/spool/cups/tmp tmpfs entry in fstab fixed the 
problem: on boot, the /run/sshd directory is created and sshd starts up 
successfully.


I'll open a fresh ticket to discuss this problem with systemd since 
their handling of directories (and tmpfs in particular) seems problematic.


Cheers,

Paul.


--
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540483ac.5000...@desy.de

Bug#645788: openssh-server: /run on tmpfs breaks sshd started, from inetd

[Russ Allbery]

Paul Millar paul.mil...@desy.de writes:

 For the record, my problem was (or appears to have been) triggered by a
 failure to mount an unrelated tmpfs file-system (/var/spool/cups/tmp)
 earlier in the boot sequence.  This failure was because /var/spool/cups
 was a symlink pointing to another partition.  If the other partition was
 not mounted when attempting to mount /var/spool/cups/tmp, the mount
 would fail.

 Removing the /var/spool/cups/tmp tmpfs entry in fstab fixed the
 problem:  on boot, the /run/sshd directory is created and sshd starts up
 successfully.

 I'll open a fresh ticket to discuss this problem with systemd since
 their handling of directories (and tmpfs in particular) seems
 problematic.

I'm not sure this is related to tmpfs.  I'm wondering if the mount process
aborted because it failed to mount a directory and nofail was not
specified for that mount.  It would be interesting to see what systemd
thought was the status of the various started services at the point at
which you thought you had a fully booted system but /run/sshd didn't
exist.

I vaguely remember some other people noting that systemd and sysvinit are
different in their handling of failures of file system mounts without
nofail specified.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx4r47jm@hope.eyrie.org

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[Paul Millar]

Package: openssh-server
Version: 1:6.6p1-7
Followup-For: Bug #645788

I've noticed the same problem.

I had inetd running, but did *not* have sshd running via inetd.

I have also verified that uninstalling (dpkg --purge) inetd does not fix the
problem.  Therefore, I'm sure that the inetd is not triggering this problem.

I noticed that running dpkg-reconfigure openssh-server creates the directory
/var/run/sshd.  To me, this suggests the underlying problem here: the debian
packaging assumes that creating /var/run/sshd directory once (during
configuration) is sufficient.  With /var/run now a sym-link to /var and that
being tmpfs, this is no longer true.

The solution is that the openssh-server package updates it's initrd and systemd
entries so that, on start up, it checks the /var/run/sshd directory and creates
it if it doesn't already exists.



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.14-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  dpkg   1.17.13
ii  init-system-helpers1.21
ii  libc6  2.19-9
ii  libcomerr2 1.42.11-2
ii  libgssapi-krb5-2   1.12.1+dfsg-7
ii  libkrb5-3  1.12.1+dfsg-7
ii  libpam-modules 1.1.8-3.1
ii  libpam-runtime 1.1.8-3.1
ii  libpam0g   1.1.8-3.1
ii  libselinux12.3-1
ii  libssl1.0.01.0.1i-2
ii  libwrap0   7.6.q-25
ii  lsb-base   4.1+Debian13
ii  openssh-client 1:6.6p1-7
ii  openssh-sftp-server1:6.6p1-7
ii  procps 1:3.3.9-7
ii  zlib1g 1:1.2.8.dfsg-2

Versions of packages openssh-server recommends:
ii  ncurses-term  5.9+20140712-2
ii  xauth 1:1.0.9-1

Versions of packages openssh-server suggests:
pn  molly-guard   none
pn  monkeysphere  none
pn  rssh  none
pn  ssh-askpass   none
pn  ufw   none

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140827100705.2557.63150.report...@zitpcx6184.desy.de

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[Colin Watson]

On Wed, Aug 27, 2014 at 12:07:05PM +0200, Paul Millar wrote:
 The solution is that the openssh-server package updates it's initrd and 
 systemd
 entries so that, on start up, it checks the /var/run/sshd directory and 
 creates
 it if it doesn't already exists.

The sysvinit script does this:

  check_privsep_dir() {
  # Create the PrivSep empty dir if necessary
  if [ ! -d /var/run/sshd ]; then
  mkdir /var/run/sshd
  chmod 0755 /var/run/sshd
  fi
  }
  [...]
  case $1 in
start)
  check_for_upstart 1
  check_privsep_dir

So does the Upstart job:

  pre-start script
  test -x /usr/sbin/sshd || { stop; exit 0; }
  test -e /etc/ssh/sshd_not_to_be_run  { stop; exit 0; }
  
  mkdir -p -m0755 /var/run/sshd
  end script

And for systemd this should be handled by a tmpfiles.d script:

  d /var/run/sshd 0755 root root

So it's not sufficient to simply state that we need to handle this,
because as far as I can see we already do.  Could you please investigate
why the respective handling for whatever init system you have as pid 1
is not working for you?  Please then take this to a separate bug report,
as this is not at all the same issue as the original one filed as
#645788, and it is not usually good to conflate multiple issues into a
single bug report.

Thanks,

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


-- 
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140827104220.gl5...@riva.ucam.org

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[Colin Watson]

On Tue, Oct 18, 2011 at 06:56:07PM +0200, Dirk Heinrichs wrote:
 I'm running sshd with priviledge separation enabled from inetd, but
 since some time I can't login anymore after reboot.
 
 In /var/log/auth.log, I see the followin message:
 
 fatal: Missing privilege separation directory: /var/run/sshd
 
 The reason for this is that /var/run is now a symlink to /run, which
 is mounted as a tmpfs, thus it doesn't survive a reboot.

I'm not sure what I can do about this.  The init script ensures that
/var/run/sshd exists; isn't it your responsibility to make suitable
arrangements when locally configuring sshd to start from inetd?

(I suppose you could argue that the Debian packaging should set the
privsep path to /var/lib/sshd instead.  That seems quite difficult to
change now though ...)

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



-- 
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120224085542.gx3...@riva.dynamic.greenend.org.uk

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[Dirk Heinrichs]

Am 24.02.2012 09:55, schrieb Colin Watson:

On Tue, Oct 18, 2011 at 06:56:07PM +0200, Dirk Heinrichs wrote:

I'm running sshd with priviledge separation enabled from inetd, but
since some time I can't login anymore after reboot.

In /var/log/auth.log, I see the followin message:

fatal: Missing privilege separation directory: /var/run/sshd

The reason for this is that /var/run is now a symlink to /run, which
is mounted as a tmpfs, thus it doesn't survive a reboot.


I'm not sure what I can do about this.  The init script ensures that
/var/run/sshd exists; isn't it your responsibility to make suitable
arrangements when locally configuring sshd to start from inetd?


Well, that's what I did, of course. I've put this into /etc/rc.local:

[[ -d /run/sshd ]] || mkdir -p /run/sshd


(I suppose you could argue that the Debian packaging should set the
privsep path to /var/lib/sshd instead.  That seems quite difficult to
change now though ...)


Hmm, why has it been changed from the default (/var/empty) in the first 
place?


If the package would simply do what README.privsep says, everything 
would be fine, no matter how sshd is finally invoked. From README.privsep:


You should do something like the following to prepare the privsep
preauth environment:

# mkdir /var/empty
# chown root:sys /var/empty
# chmod 755 /var/empty
# groupadd sshd
# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

/var/empty should not contain any files.

configure supports the following options to change the default
privsep user and chroot directory:

  --with-privsep-path=xxx Path for privilege separation chroot
  --with-privsep-user=user Specify non-privileged user for privilege 
separation


Bye...

Dirk



--
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f47d6fa.2000...@altum.de

Bug#645788: openssh-server: /run on tmpfs breaks sshd started from inetd

[Dirk Heinrichs]

Package: openssh-server
Version: 1:5.9p1-1
Severity: important

Dear Maintainer,

I'm running sshd with priviledge separation enabled from inetd, but since some 
time I can't login anymore after reboot.

In /var/log/auth.log, I see the followin message:

fatal: Missing privilege separation directory: /var/run/sshd

The reason for this is that /var/run is now a symlink to /run, which is mounted 
as a tmpfs, thus it doesn't survive a reboot.

Bye...

Dirk

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.39.4
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser3.113
ii  debconf [debconf-2.0]  1.5.40   
ii  dpkg   1.16.1   
ii  libc6  2.13-21  
ii  libcomerr2 1.42~WIP-2011-07-02-1
ii  libgcc11:4.6.1-4
ii  libgssapi-krb5-2   1.9.1+dfsg-1 
ii  libkrb5-3  1.9.1+dfsg-1 
ii  libpam-modules 1.1.3-4  
ii  libpam-runtime 1.1.3-4  
ii  libpam0g   1.1.3-4  
ii  libselinux12.1.0-1  
ii  libssl1.0.01.0.0e-2 
ii  libwrap0   7.6.q-21 
ii  lsb-base   3.2-28   
ii  openssh-client 1:5.9p1-1
ii  procps 1:3.2.8-11   
ii  zlib1g 1:1.2.3.4.dfsg-3 

Versions of packages openssh-server recommends:
ii  openssh-blacklist0.4.1
ii  openssh-blacklist-extra  0.4.1
ii  xauth1:1.0.6-1

Versions of packages openssh-server suggests:
pn  molly-guard   none
pn  monkeysphere  none
pn  rssh  none
pn  ssh-askpass   none
pn  ufw   none

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111018165607.6010.85252.report...@rohan.altum.de