Solución 1:
Un error que cometiste fue intentar iniciar sshd a mano.
Si, en cambio, inicia sshd a través de medios oficiales debería funcionar. El service comando 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 los scripts de inicio de sysv, eso es todo lo que necesita hacer. La razón por la que falta el directorio es que /var/run es un enlace simbólico a /run y /run es un tmpfs punto de montaje. Eso significa que en cada arranque /var/run comenzará vacío. Cuando usas el service comanda el /etc/init.d/ssh la secuencia de comandos se usará para iniciar sshd pero antes de hacerlo, el script creará /var/run/sshd si no existe.
Con systemd las cosas funcionan un poco diferente. Habrá un archivo llamado /usr/lib/tmpfiles.d/sshd.conf con este contenido:
d /var/run/sshd 0755 root root
Durante el arranque, esto debería causar el /var/run/sshd directorio a crear. Lo que necesita para verificar que el archivo existe y tiene el contenido correcto. Si el /var/run/sshd todavía falta el directorio, puede verificar si se crea cuando ejecuta systemd-tmpfiles --create manualmente.
Solución 2:
Entonces /run (y /var/run vinculado a él) se vuelve a crear cada reinicio. Excepto que systemd-tmpfiles no está haciendo eso para algunos archivos, incluidos (/var)/run/sshd.
Aparentemente, esto se solucionó con una actualización del kernel de OpenVZ. Pero para arreglarlo ahora, edita /usr/lib/tmpfiles.d/sshd.conf y eliminar /var de la línea d /var/run/sshd 0755 root root para leer en su lugar:
d /run/sshd 0755 root root
Y eso es todo..!
Y cuando se actualice el servidor openssh, esperamos que hayan solucionado este error (¿o es realmente un error en systemd? ¿o en openvz?), De lo contrario, podría encontrarse con el mismo problema.
Solución 3:
Aparentemente, esto se resuelve cuando se ejecuta un kernel OpenVZ 2.6.32-042stab134.7 o posterior. Me parece extraño que no haya una solución posible en los scripts de inicio de systemd de alguna manera. Probablemente un truco feo como crear automáticamente /run/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 iniciaran porque systemd-tmpfiles no pudo validar la ruta debido a problemas de enlace simbólico. (PSBM-90038)
Solución 4:
A pesar de los problemas que he tenido con systemd a lo largo de los años, debo admitir que este problema se deriva en cambio de la sincronización de Ansible directiva.
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 de root. Después de ejecutar chown para corregir las cosas, /var/run/sshd ahora se crea en el arranque de nuevo.
Realmente aprecio todos los aportes, pero no hay ningún error aquí, al menos en el sentido de que aplicar una propiedad inapropiada a los directorios raíz provocó un comportamiento indefinido del sistema.