Pourquoi me manque-t-il / var / run / sshd après chaque démarrage?

14

J'utilise un conteneur Ubuntu 16.04 sous Proxmox 5.2-11. Après avoir appliqué la dernière série de correctifs 1, je ne parviens pas à me connecter à la console ou via ssh.

J'ai monté le conteneur racine FS sur l'hyperviseur et ajouté pts/0à /etc/security/access.conf(nous exécutons pam_access) et qui permettait la connexion root à la console. Nous avons root : lxc/tty0 lxc/tty1 lxc/tty2dans access.conflequel je pensais que c'était suffisant, alors pourquoi j'avais besoin pts/0maintenant est déroutant.

J'ai remarqué que ssh ne fonctionnait pas, j'ai donc essayé de le démarrer à la main ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) et j'ai reçu cette erreur:

Missing privilege separation directory: /var/run/sshd

J'ai créé le répertoire à la main, j'ai démarré sshet j'ai finalement pu me connecter, mais après un redémarrage, le problème persiste. Le répertoire n'est pas en cours de création. Seuls les bits utiles journalctlet la seule partie intéressante concernent "l'opération non autorisée" mais pas d'autres informations.

Je ne connais pas trop la version 16.04, je me demande donc comment en savoir plus sur le problème. Je n'ai pas /var/log/syslogou /var/log/messagesseulement kern.logsi peu perdu.

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 --createSortie ajoutée

Vraiment bizarre .... J'ai vérifié /tmpet ces fichiers n'existent pas entrez la description de l'image ici

linux ssh permissions systemd proxmox Défaillance du serveur
la source

Réponses:

11

Vous avez fait une erreur en essayant de commencer sshdà la main.

Si vous commencez sshdpar des moyens officiels, cela devrait simplement fonctionner. La servicecommande sait quelle est la bonne façon de démarrer un service sur votre distribution, et cela devrait fonctionner:

service ssh start

Dans le cas des scripts d'initialisation sysv, c'est tout ce que vous devez faire. La raison pour laquelle le répertoire est manquant est qu'il /var/runs'agit d'un lien symbolique vers /runet /runest un tmpfspoint de montage. Cela signifie que chaque démarrage /var/runcommencera vide. Lorsque vous utilisez la servicecommande, le /etc/init.d/sshscript sera utilisé pour démarrer, sshdmais avant de le faire, le script sera créé /var/run/sshds'il n'existe pas.

Avec les systemdchoses fonctionnent un peu différemment. Il y aura un fichier appelé /usr/lib/tmpfiles.d/sshd.confavec ce contenu:

d /var/run/sshd 0755 root root

Au démarrage, cela devrait entraîner la /var/run/sshdcréation du répertoire. Ce dont vous avez besoin pour vérifier que le fichier existe et a le contenu correct. Si le /var/run/sshdrépertoire est toujours manquant, vous pouvez vérifier s'il est créé lorsque vous l'exécutez systemd-tmpfiles --createmanuellement.

kasperd
la source
C'est une bonne idée mais fait essentiellement la même chose que le système a essayé de faire au démarrage (et a échoué de la même manière). Ce que je me demande vraiment, c'est pourquoi le répertoire privsep n'est pas créé par des moyens normaux. Y a-t-il une erreur de disque? Un problème d'autorisation? verrouiller le fichier? Où chercher ailleurs journalctl?
Défaillance du serveur
@ServerFault Dans certaines circonstances /etc/init.d/ssh, ne sera pas exécuté et systemctlsera utilisé à la place. Et quand sshdest démarré via systemctlle répertoire n'est pas créé. Cela laisse quelques questions ouvertes que j'essaierai de creuser demain, telles que ce qui a exactement changé et comment exactement ce répertoire est censé être créé lorsqu'il systemctlest utilisé.
kasperd
@ServerFault Lors de son utilisation, systemctlc'est lui /etc/init/ssh.confqui est responsable de la création du répertoire. J'ai testé sur un Ubuntu 16.04 entièrement à jour et le répertoire est créé lors du démarrage. Mais pour une raison quelconque, il n'est pas créé lors de l'utilisation service ssh start. Il existe des mises à jour récentes de certains systemdpackages associés, mais je ne vois aucune preuve de comportement concernant la création de ce répertoire ayant changé. Et lorsque je teste, il est créé lors du démarrage. La question est donc de savoir si votre /etc/init/ssh.confcontenu est correct.
kasperd
@ServerFault Je me suis peut-être trompé sur /etc/init/ssh.confce /usr/lib/tmpfiles.d/sshd.confqui semble également être utilisé par systemd-tmpfiles --create. Crée systemd-tmpfiles --createle /var/run/sshdrépertoire manquant ?
kasperd
Ajout d'une image pour remettre en question la systemd-tmpfiles --createsortie. Le "symlinks" systemd se plaint de (/tmp/.X11-unix) n'existe même pas, /tmp/donc je n'ai aucune idée d'où ça vient. Merci pour toute votre aide, mais je pense que je vais continuer.
Défaillance du serveur
10

Ainsi, / run (et / var / run lié à celui-ci) est recréé à chaque redémarrage. Sauf que systemd-tmpfiles ne le fait pas pour certains fichiers, y compris (/ var) / run / sshd.

Apparemment, cela est résolu par une mise à niveau du noyau OpenVZ. Mais pour le corriger maintenant, vous éditez /usr/lib/tmpfiles.d/sshd.confet supprimez /varde la ligne d /var/run/sshd 0755 root rootpour lire à la place: d /run/sshd 0755 root root

Et c'est tout..!

Et lorsque openssh-server sera mis à niveau, nous espérons qu'ils auront corrigé ce bogue (ou est-ce vraiment un bogue dans systemd? Ou openvz ??) - sinon vous pourriez rencontrer le même problème.

pepa65
la source
1
+1 pour le correctif en attendant une mise à niveau du noyau. Dans mon cas, il devait devenir: "root root d / run / sshd 0755"
paulzag
1
@paulzag Cela a également fonctionné pour moi. Je me demande si @ pepa65 voulait dire d /run/sshd 0755 root root, car leurs instructions disent de ne supprimer que la /varpartie (même si le code qu'ils donnent dans la réponse a les deux /varet /runsupprimé).
Stephen Schrauger
4

Apparemment, cela est résolu lors de l'exécution d'un noyau OpenVZ 2.6.32-042stab134.7 ou plus récent. Je trouve étrange qu'il n'y ait aucun correctif possible dans les scripts de démarrage de systemd d'une manière ou d'une autre. Un hack laid comme la création automatique de / run / sshd / après le démarrage puis le démarrage de sshd fonctionnerait probablement.

La sortie de mon 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

Le journal des modifications d'OpenVZ 2.6.32-042stab134.7 dit ceci:

L'exécution de conteneurs Ubuntu avec systemd 229-4ubuntu21.9 pourrait entraîner l'échec du démarrage des services car systemd-tmpfiles n'a pas pu valider le chemin d'accès en raison de problèmes de liaison symbolique. (PSBM-90038)

pepa65
la source
2

Pour autant de problèmes que j'ai eu avec systemd au fil des ans, je dois admettre que ce problème provient plutôt de la directive de synchronisation Ansible .

Pour une raison quelconque, après avoir provisionné cet hôte avec nos scripts ansbile, il a laissé le répertoire / (ainsi que / etc, / opt et autres) appartenant à un utilisateur administrateur, et non root. Après avoir exécuté chownpour corriger les choses, /var/run/sshdest maintenant créé à nouveau au démarrage.

J'apprécie vraiment toutes les entrées, mais il n'y a pas de bogue ici, au moins dans le sens où appliquer une propriété inappropriée aux répertoires racine a provoqué un comportement système non défini.

Défaillance du serveur
la source
Cette! Merci pour le conseil, Ansible était aussi le coupable dans notre cas!
Beenish Khan