web-dev-qa-db-fra.com

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

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é la racine du conteneur FS sur l'hyperviseur et ajouté pts/0 à /etc/security/access.conf (nous courrons pam_access) et qui permettait la connexion root à la console. On a root : lxc/tty0 lxc/tty1 lxc/tty2 dans access.conf ce que je pensais suffisant alors pourquoi j'avais besoin de pts/0 est maintenant 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 a reçu cette erreur:

Missing privilege separation directory: /var/run/sshd

J'ai créé le répertoire à la main, démarré ssh et 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 dans journalctl et la seule partie intéressante est quelque chose sur "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/syslog ou /var/log/messages seulement kern.log tellement 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

Ajouté systemd-tmpfiles --create sortie

Vraiment bizarre .... J'ai vérifié /tmp et ces fichiers n'existent pas enter image description here

14
Server Fault

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 Ansible synchronize.

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é chown pour corriger les choses, /var/run/sshd est à nouveau créé 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ù l'application d'une propriété inappropriée aux répertoires racine a provoqué un comportement système non défini.

2
Server Fault

Vous avez fait une erreur en essayant de démarrer sshd à la main.

Si vous démarrez plutôt sshd par des moyens officiels, cela devrait fonctionner. La commande service 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 que /var/run est un lien symbolique vers /run et /run est un point de montage tmpfs. Cela signifie à chaque démarrage /var/run commencera vide. Lorsque vous utilisez la commande service, la commande /etc/init.d/ssh le script sera utilisé pour démarrer sshd mais avant cela, le script créera /var/run/sshd s'il n'existe pas.

Avec systemd les choses fonctionnent un peu différemment. Il y aura un fichier appelé /usr/lib/tmpfiles.d/sshd.conf avec ce contenu:

d /var/run/sshd 0755 root root

Au démarrage, cela devrait provoquer le /var/run/sshd répertoire à créer. Ce dont vous avez besoin pour vérifier que le fichier existe et a le contenu correct. Si la /var/run/sshd le répertoire est toujours manquant, vous pouvez vérifier s'il est créé lorsque vous exécutez systemd-tmpfiles --create manuellement.

11
kasperd

Donc/run (et/var/run en lien symbolique avec lui) 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 y remédier maintenant, vous éditez /usr/lib/tmpfiles.d/sshd.conf et supprimez /var de la ligne d /var/run/sshd 0755 root root à 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.

11
pepa65

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)

4
pepa65