El servidor SSH deja de funcionar después de reiniciar, debido a la falta de / var / run / sshd

23

Mi VPS no se reinició durante aproximadamente 3 meses. Está alojado en un servidor con el tipo de virtualización OpenVZ y el sistema operativo es Ubuntu 16.04. Por alguna razón, reinicié el VPS y después de eso, no pude conectarme al servidor a través de ssh, el mensaje que recibí es:

ssh: connect to host srvname.com port 22: Connection refused

Así que abrí una consola serie en el VPS y comencé a investigar ... He purgado y reinstalado el openssh-serversin éxito. Pasé dos horas leyendo artículos, preguntas y respuestas sobre problemas similares en Internet.

Finalmente logré entender que el directorio /var/run/sshdno se creó durante el inicio del sistema. Y una vez que lo creo manualmente, puedo iniciar el servicio SSH sin ningún problema, pero en el próximo reinicio el problema persiste. Entonces mis preguntas son:

  • ¿Cuál podría ser la causa de este problema? ¿Por qué /var/run/sshdno se crea durante el inicio del sistema?

  • ¿Cómo puedo resolver el problema de manera adecuada? Encontré una solución temporal que se menciona al final de esta publicación.

  • ¿El problema podría estar relacionado con el host OpenVZ del VPS? ¿Debo pedirle al proveedor de hosting que lo resuelva?


La salida de systemctl status ssh.service, sshd -Ddp 22y journalctl -xees:

# systemctl status ssh.service
 ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: start-limit-hit) since вт 2019-01-15 12:58:08 EET; 22s ago
  Process: 407 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)

яну 15 12:58:07 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 12:58:08 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 12:58:08 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.


# $(which sshd) -Ddp 22
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ssh-dss SHA256:...
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:...
debug1: private host key #3: ssh-ed25519 SHA256:...
Missing privilege separation directory: /var/run/sshd


# journalctl -xe
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has begun starting up.
яну 15 13:21:21 srvname sshd[1688]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:21 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:21 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: Starting OpenBSD Secure Shell server...
-- Subject: Unit ssh.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has begun starting up.
яну 15 13:21:22 srvname sshd[1691]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:22 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.

El contenido de /usr/lib/tmpfiles.d/sshd.confy /etc/init/ssh.confes:

# cat /usr/lib/tmpfiles.d/sshd.conf 
d /var/run/sshd 0755 root root

# cat /etc/init/ssh.conf | sed '/^#/ d'

description "OpenSSH server"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5
umask 022

env SSH_SIGSTOP=1
expect stop

console none

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

exec /usr/sbin/sshd -D

Información adicional sobre el sistema:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:   xenial

# uname -a
Linux srvname 2.6.32-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

# apt show openssh-server | grep 'Version'
Version: 1:7.2p2-4ubuntu2.6

La solución temporal: descubrí que /var/runes un enlace simbólico /run, no sé por qué es necesario, pero cuando modifiqué el contenido del archivo /usr/lib/tmpfiles.d/sshd.confde:

d /var/run/sshd 0755 root root

a:

d /run/sshd 0755 root root

todo funciona bien en el inicio del sistema, el servicio SSH se inicia normalmente y puedo iniciar sesión a través de SSH.

pa4080
fuente
Este problema puede aparecer repentinamente después de un reinicio debido a una actualización de versión que se realizó justo antes de ese reinicio, como se describe en esta pregunta vinculada . La lección: no actualice a menos que esté seguro de que su núcleo puede soportarlo.
Nieve

Respuestas:

24

Encontré que este es un error con la versión actual de systemd y kernels antiguos que usan algunos VPS como en mi caso. Este error aparece de vez en cuando, como podemos ver en Launchpad: Bug # 45234 , Bug # 1811580 ; o en ServerFault: ¿Por qué me falta / var / run / sshd después de cada arranque?

Hay pocas soluciones a este problema, todas se unen para crear una forma alternativa /var/run/sshdantes de ejecutar el servidor SSH. Aquí hay tres posibles soluciones.


Solución 1: modifique /usr/lib/tmpfiles.d/sshd.confde la siguiente manera:

d /run/sshd 0755 root root

Como se menciona en la pregunta, /var/runes un enlace simbólico /run, el resultado final es idéntico: /var/run/sshdse crea. No sé por qué, pero esto funciona.


Solución 2: use el trabajo Cron que creará /var/run/sshdy reiniciará el servidor SSH, puede usar la raíz crontabpara este propósito: ejecute sudo crontab -ey agregue la siguiente entrada:

@reboot mkdir -p -m0755 /var/run/sshd && systemctl restart ssh.service

Actualmente estoy usando esta solución, por lo que también está probada.


Solución 3: utilice /etc/rc.localpara hacer lo mismo que el anterior, como se muestra en este comentario en el informe de error # 45234.

pa4080
fuente
1
Gracias, eso soluciona ssh pero no los problemas más amplios de que systemd se rompa. Intente ejecutar systemd-tmpfiles --cree y vea todos los errores
paulzag
1
Tienes razón, @paulzag, pero en mi caso estoy seguro de que el problema general es el núcleo antiguo. Decidí ignorar estos errores que se systemd-tmpfiles --createmuestran, porque en este momento no hay ningún mal funcionamiento sensible en el servidor. En general, el La pregunta actual es sobre cómo hacer que el servicio SSH esté operativo después de reiniciar mientras el problema está activado. Si lo desea, puede votar la solución :)
pa4080
La "Solución 1" funcionó para mí ... Gracias ... Votado ...
Biswadeep Sarkar
2
Sería más apropiado reemplazarlo en /usr/lib/tmpfiles.d/sshd.conf lugar de modificarlo directamente, ya que el administrador de paquetes administra ese archivo. Para hacerlo, simplemente haga el cambio /etc/tmpfiles.d/sshd.conf; esto tendrá prioridad sobre el sshd.confin /usr/lib. Vea esta sección en tmpfiles.d (5) . Gran respuesta independientemente, estar en un VPS OpenVZ es exactamente la situación en la que me he encontrado.
ZeroKnight
1
En cuanto a por qué funciona la solución 1 ; está evitando usar el /var/runenlace simbólico, que es con lo systemd-tmpfilesque tiene un problema y por qué no se crea el directorio PrivSep. El cuarto y último mensaje de este hilo arroja algo de luz sobre esto. De acuerdo, es respecto systemd-tmpfiles-clean, pero tengo la sensación de que aquí se aplica lo mismo.
ZeroKnight
1

¿Podría verificar si sus /permisos (del sistema de archivos raíz) no han cambiado? Tiene que ser root:rootcomo las dos líneas a continuación:

drwxr-xr-x  25 root root      4096 дек 21 06:45 ..
drwxr-xr-x  25 root root      4096 дек 21 06:45 .

Si el propietario es otro usuario (y no root), esto evitará la creación de todos los archivos temporales por systemd durante el inicio del sistema. Puede verificar también con el comando:

systemd-tmpfiles --create

Si la carpeta raíz ( /) tiene un permiso diferente, cámbiela con el siguiente comando:

chown root: /
Stefan
fuente
0

Gracias a todos por la información útil. El problema con ssh-server en mi Xenial Lubuntu estaba relacionado con la propiedad de '/' como lo sugirieron Melebius & Stefan.
Creación /var/run/sshdy reinicio manual de ssh.service temporalmente ssh-server temporalmente. La edición de sshd.confno ayudó en este sistema. Luego, siguiendo la última sugerencia, verifiqué la propiedad de la carpeta raíz con:

' ls -alF /' y efectivamente, se había cambiado accidentalmente a un usuario / grupo local. Emitiendo desde el terminal: ' sudo chown root:root /' reparó mi sistema, independientemente de la edición a sshd.conf. Así que restauré eso a su estado original, es decir d /var/run/sshd 0755 root root.

Miguel
fuente
0

Tengo este problema en mi máquina cuando ejecuto varias instancias de sshd en una sola máquina (18.04.02 LTS, OpenSSH 7.6p1).

El problema es que no hay conmutadores en sshd (es decir, la línea de comandos o el sshd_configarchivo) aprovisionados para cambiar la ubicación del "directorio de separación de privilegios". El directorio debe estar en el /var/empty, de acuerdo con el código fuente de OpenSSH 7.6p1.

El paquete de Ubuntu ha reasignado esto a /run/sshd.

Hay un problema de "seguridad de subprocesos" en los init.dscripts en el arranque cuando ambos scripts de servicio intentan crear el directorio. Le he pedido a Ubuntu y OpenSSH que aborden el problema de los nombres de ruta de "directorio de separación de privilegios" codificados en sshd. Si pudiera cargar archivos, tengo el fijo basado en el código fuente de OpenSSH 8.0p1.

Luke A Perkins
fuente