¿Por qué me falta / var / run / sshd después de cada arranque?

14

Estoy ejecutando un contenedor Ubuntu 16.04 en Proxmox 5.2-11. Después de aplicar la última ronda de parches 1, no puedo iniciar sesión en la consola o sobre ssh.

Monté el FS raíz de contenedores en el hipervisor y añadió pts/0a /etc/security/access.conf(corremos pam_access) y la conexión de la raíz que permite a la consola. Tenemos root : lxc/tty0 lxc/tty1 lxc/tty2en access.conflo que pensé que era suficiente, así que por qué lo necesitaba pts/0ahora es desconcertante.

Noté que ssh no se estaba ejecutando, así que intenté iniciarlo a mano ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) y recibí este error:

Missing privilege separation directory: /var/run/sshd

Creé el directorio a mano, comencé sshy finalmente pude iniciar sesión, pero después de reiniciar, el problema persiste. El directorio no se está creando. Solo bits útiles journalctly la única parte interesante es algo sobre "operación no permitida" pero no más información.

No estoy muy familiarizado con 16.04, así que me pregunto cómo puedo encontrar más información sobre el problema. No tengo /var/log/syslogni tan /var/log/messagessolo un kern.logpoco perdido.

1

systemd-sysv 229-4ubuntu21.9
libpam-systemd 229-4ubuntu21.9
libsystemd0 229-4ubuntu21.9
systemd 229-4ubuntu21.9
udev 229-4ubuntu21.9
libudev1 229-4ubuntu21.9
iproute2 4.3.0-1ubuntu3.16.04.4
libsasl2-modules-db 2.1.26.dfsg1-14ubuntu0.1
libsasl2-2 2.1.26.dfsg1-14ubuntu0.1
ldap-utils 2.4.42dfsg-2ubuntu3.4
libldap-2.4-2 2.4.42dfsg-2ubuntu3.4
libsasl2-modules 2.1.26.dfsg1-14ubuntu0.1
libgs9-common 9.25dfsg1-0ubuntu0.16.04.3
ghostscript 9.25dfsg1-0ubuntu0.16.04.3
libgs9 9.25dfsg1-0ubuntu0.16.04.3

[2]

Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[474]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 mysqld_safe[495]: Starting mysqld daemon with databases from /var/lib/mysql/mysql
Nov 27 10:13:48 host16 mysqld[500]: 181127 10:13:48 [Note] /usr/sbin/mysqld (mysqld 10.0.36-MariaDB-0ubuntu0.16.04.1) starting as process 499 ...
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[502]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[503]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[504]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:49 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Start request repeated too quickly.
Nov 27 10:13:49 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Failed with result 'start-limit-hit'.
Nov 27 10:13:49 host16 systemd[1]: Started /etc/rc.local Compatibility.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Terminate Plymouth Boot Screen...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit-wait.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Hold until boot process finishes up...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/rc-local.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Hold until boot process finishes up.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/1.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/0.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/console-getty.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Console Getty.
Nov 27 10:13:49 host16 systemd[1]: Reached target Login Prompts.
Nov 27 10:13:49 host16 systemd[1]: Started Terminate Plymouth Boot Screen.
Nov 27 10:13:52 host16 nslcd[338]: accepting connections
Nov 27 10:13:52 host16 nslcd[275]:    ...done.
Nov 27 10:13:52 host16 systemd[1]: Started LSB: LDAP connection daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/cron.service: Operation not permitted
Nov 27 10:13:52 host16 systemd[1]: Started Regular background program processing daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/atd.service: Operation not permitted

systemd-tmpfiles --createSalida agregada

Realmente extraño ... Lo comprobé /tmpy esos archivos no existen

— Falla del servidor
fuente

11

Un error que cometiste fue intentar comenzar sshda mano.

Si, en cambio, comienza a sshdtravés de medios oficiales, debería funcionar. El servicecomando sabe cuál es la forma correcta de iniciar un servicio en su distribución, y esto debería funcionar:

service ssh start

En el caso de sysv init scripts, eso es todo lo que necesita hacer. La razón por la que falta el directorio es que /var/runes un enlace simbólico /runy /runes un tmpfspunto de montaje. Eso significa que en cada arranque /var/runcomenzará vacío. Cuando use el servicecomando, el /etc/init.d/sshscript se usará para comenzar, sshdpero antes de hacerlo, el script se creará /var/run/sshdsi no existe.

Con las systemdcosas funcionan un poco diferente. Habrá un archivo llamado /usr/lib/tmpfiles.d/sshd.confcon este contenido:

d /var/run/sshd 0755 root root

Durante el arranque, esto debería hacer /var/run/sshdque se cree el directorio. Lo que necesita para verificar que el archivo existe y tiene el contenido correcto. Si /var/run/sshdtodavía falta el directorio, puede verificar si se crea cuando se ejecuta systemd-tmpfiles --createmanualmente.

— kasperd
fuente

Esa es una buena idea, pero esencialmente está haciendo lo mismo que el sistema intentó hacer en el arranque (y falló de la misma manera). Lo que realmente me pregunto es por qué el directorio privsep no se crea de manera normal. ¿Hay un error de disco? ¿Un problema de permiso? archivo de bloqueo? ¿En algún otro lugar para mirar además journalctl?

— Error del servidor el

@ServerFault En determinadas circunstancias /etc/init.d/ssh, no se ejecutará y systemctlse utilizará en su lugar. Y cuando sshdse inicia a través systemctldel directorio no se crea. Eso deja algunas preguntas abiertas en las que intentaré profundizar mañana, como qué ha cambiado exactamente y cómo se supone que se creará ese directorio cuando systemctlse use.

— kasperd

@ServerFault Cuando se usa systemctl, /etc/init/ssh.confes el responsable de crear el directorio. Probé en un Ubuntu 16.04 completamente actualizado y el directorio se creó durante el arranque. Pero por alguna razón no se crea cuando se usa service ssh start. Hay algunas actualizaciones recientes de algunos systemdpaquetes relacionados, pero no veo ninguna evidencia de comportamiento con respecto a la creación de ese directorio que ha cambiado. Y cuando lo pruebo, se crea durante el arranque. Entonces la pregunta es si /etc/init/ssh.conftiene el contenido correcto.

— kasperd

@ServerFault Es posible que me haya equivocado acerca de /etc/init/ssh.confque también existe el /usr/lib/tmpfiles.d/sshd.confque parece ser utilizado por systemd-tmpfiles --create. ¿ systemd-tmpfiles --createCrea el /var/run/sshddirectorio que falta ?

— kasperd el

Se agregó una foto a la pregunta de la systemd-tmpfiles --createsalida. Los "enlaces simbólicos" de los que se queja systemd (/tmp/.X11-unix) ni siquiera existen, /tmp/así que no tengo idea de dónde está obteniendo eso. Gracias por toda su ayuda, pero creo que voy a seguir adelante.

— Falla del servidor el

10

Entonces / run (y / var / run enlazado a él) se recrean cada reinicio. Excepto que systemd-tmpfiles no está haciendo eso para algunos archivos que incluyen (/ var) / run / sshd.

Aparentemente, esto se soluciona mediante una actualización del núcleo de OpenVZ. Pero para solucionarlo ahora, edita /usr/lib/tmpfiles.d/sshd.confy elimina /varde la línea d /var/run/sshd 0755 root rootpara leer en su lugar:d /run/sshd 0755 root root

Y eso es..!

Y cuando se actualice openssh-server, esperamos que hayan solucionado este error (¿o es realmente un error en systemd? O openvz ??); de lo contrario, podría encontrarse con el mismo problema.

— pepa65
fuente

1

+1 para la solución mientras espera una actualización de Kernel. En mi caso, debía convertirse en: "d / run / sshd 0755 root root"

— paulzag

1

@paulzag Eso también funcionó para mí. Me pregunto si @ pepa65 quería decir d /run/sshd 0755 root root, ya que sus instrucciones dicen que solo se elimine la /varparte (a pesar de que el código que dan en la respuesta tiene ambos /vary se /runeliminó).

— Stephen Schrauger

4

Aparentemente, esto se resuelve cuando se ejecuta un kernel OpenVZ 2.6.32-042stab134.7 o posterior. Me resulta extraño que no haya una solución posible en los scripts de inicio del sistema de alguna manera. Probablemente un truco feo como crear automáticamente / ejecutar / sshd / después de iniciar y luego iniciar sshd funcionaría.

La salida de mi systemd-tmpfiles --create:

[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
fchownat() of /run/named failed: Invalid argument
Failed to openat(/dev/simfs): Operation not permitted
Failed to validate path /var/run/screen: Too many levels of symbolic links
Failed to validate path /var/run/sshd: Too many levels of symbolic links
Failed to validate path /var/run/sudo: Too many levels of symbolic links
Failed to validate path /var/run/sudo/ts: Too many levels of symbolic links
fchownat() of /run/systemd/netif failed: Invalid argument
fchownat() of /run/systemd/netif/links failed: Invalid argument
fchownat() of /run/systemd/netif/leases failed: Invalid argument
fchownat() of /run/log/journal failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc/system.journal failed: Invalid argument

El registro de cambios de OpenVZ 2.6.32-042stab134.7 dice esto:

La ejecución de contenedores de Ubuntu con systemd 229-4ubuntu21.9 podría provocar que los servicios no se inicien porque systemd-tmpfiles no pudo validar la ruta debido a problemas de enlace simbólico. (PSBM-90038)

— pepa65
fuente

2

Por todos los problemas que he tenido con systemd a lo largo de los años, debo admitir que este problema se deriva de la directiva de sincronización Ansible .

Por alguna razón, después de aprovisionar este host con nuestros scripts ansbile, dejó el directorio / (así como / etc, / opt y otros) propiedad de un usuario administrador, y no root. Después de correr chownpara corregir las cosas, /var/run/sshdahora se crea en el arranque nuevamente.

Realmente aprecio toda la entrada, pero no hay ningún error aquí, al menos en el sentido de que aplicar una propiedad inapropiada a los directorios raíz causó un comportamiento indefinido del sistema.

— Falla del servidor
fuente

¡Esta! Gracias por el consejo, ¡Ansible fue el culpable en nuestro caso también!

— Beenish Khan