Le serveur SSH cesse de fonctionner après le redémarrage, en raison de / var / run / sshd manquant


23

Mon VPS n'a pas été redémarré depuis environ 3 mois. Il est hébergé sur un serveur avec le type de virtualisation OpenVZ et le système d'exploitation est Ubuntu 16.04. Pour une raison quelconque, j'ai redémarré le VPS et après cela, je n'ai pas pu me connecter au serveur via ssh, le message que j'ai reçu est:

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

J'ai donc ouvert une console série sur le VPS et commencé à enquêter ... J'ai purgé et réinstallé le openssh-serversans succès. J'ai passé deux heures à lire des articles, des questions et des réponses sur des problèmes similaires sur Internet.

Enfin j'ai réussi à comprendre que le répertoire /var/run/sshdn'est pas créé lors du démarrage du système. Et une fois que je l'ai créé manuellement, je peux démarrer le service SSH sans aucun problème, mais au prochain redémarrage, le problème persiste. Mes questions sont donc:

  • Quelle pourrait être la cause de ce problème? Pourquoi /var/run/sshdn'est-il pas créé lors du démarrage du système?

  • Comment puis-je résoudre le problème de manière appropriée? J'ai trouvé une solution temporelle qui est mentionnée à la fin de ce post.

  • Le problème pourrait-il être lié à l'hôte OpenVZ du VPS? Dois-je demander au hébergeur de le résoudre?


La sortie de systemctl status ssh.service, sshd -Ddp 22et journalctl -xeest:

# 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'.

Le contenu de /usr/lib/tmpfiles.d/sshd.confet /etc/init/ssh.confest:

# 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

Informations supplémentaires sur le système:

# 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 solution temporelle: j'ai trouvé qu'il /var/runs'agit d'un lien symbolique vers /run, je ne sais pas pourquoi cela est nécessaire, mais quand j'ai modifié le contenu du fichier à /usr/lib/tmpfiles.d/sshd.confpartir de:

d /var/run/sshd 0755 root root

à:

d /run/sshd 0755 root root

tout se passe bien au démarrage du système, le service SSH démarre normalement et je peux me connecter via SSH.


Ce problème peut apparaître soudainement après un redémarrage en raison d'une mise à niveau de version effectuée juste avant ce redémarrage, comme décrit dans cette question liée . La leçon: ne mettez pas à niveau sauf si vous êtes sûr que votre noyau peut le prendre en charge.
Neige

Réponses:


24

J'ai trouvé que c'était un bug avec la version actuelle de systemd et les anciens noyaux qui sont utilisés par certains privilèges VPS comme c'est le cas dans mon cas. Ce bogue apparaît de temps en temps, comme on peut le voir sur Launchpad: bogue n ° 45234 , bogue n ° 1811580 ; ou sur ServerFault: Pourquoi suis-je manquant / var / run / sshd après chaque démarrage?

Il existe peu de solutions de contournement à ce problème, elles se combinent toutes pour créer de manière alternative /var/run/sshdavant d'exécuter le serveur SSH. Voici trois solutions possibles.


Solution de contournement 1: modifiez /usr/lib/tmpfiles.d/sshd.confde la manière suivante:

d /run/sshd 0755 root root

Comme il est mentionné dans la question, /var/runest un lien symbolique vers /run, le résultat final est identique: /var/run/sshdest créé. Je ne sais pas pourquoi, mais cela fonctionne.


Solution de contournement 2: utilisez la tâche Cron qui créera /var/run/sshdet redémarrera le serveur SSH, vous pouvez utiliser la racine crontabà cette fin - exécutez sudo crontab -eet ajoutez l'entrée suivante:

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

Actuellement, j'utilise cette solution, elle est donc également testée.


Solution de contournement 3: utilisez /etc/rc.localpour faire la même chose que ci-dessus, car il est indiqué dans ce commentaire sur le rapport de bogue # 45234.


1
Merci, cela corrige ssh mais pas les problèmes plus larges de rupture de systemd. Essayez d'exécuter systemd-tmpfiles --créer et voir toutes les erreurs
paulzag

1
Vous avez raison, @paulzag, mais dans mon cas, je suis sûr que le problème général est l'ancien noyau. J'ai décidé d'ignorer ces erreurs qui systemd-tmpfiles --creates'affichent, car pour le moment il n'y a pas de dysfonctionnements sensibles sur le serveur. En général, le la question actuelle est de savoir comment rendre le service SSH opérationnel après le redémarrage pendant que le problème est engagé. Si vous le souhaitez, vous pouvez voter pour la solution :)
pa4080

La "solution de contournement 1" a fonctionné pour moi ... Merci ... Voté ...
Biswadeep Sarkar

2
Il serait préférable de remplacer /usr/lib/tmpfiles.d/sshd.conf plutôt que de le modifier directement, car ce fichier est géré par le gestionnaire de packages. Pour ce faire, effectuez simplement le changement /etc/tmpfiles.d/sshd.conf; cela aura priorité sur le sshd.confin /usr/lib. Voir cette section dans tmpfiles.d (5) . Excellente réponse malgré tout, être sur un VPS OpenVZ est exactement la situation dans laquelle j'ai rencontré cela.
ZeroKnight

1
Quant à savoir pourquoi la solution de contournement 1 fonctionne; vous évitez d'utiliser le /var/runlien symbolique, ce qui systemd-tmpfilespose problème et pourquoi le répertoire PrivSep n'est pas créé. Le 4ème dernier message de ce fil nous éclaire. Certes, c'est inquiétant systemd-tmpfiles-clean, mais j'ai le sentiment que la même chose s'applique ici.
ZeroKnight

1

Pourriez-vous vérifier si vos /autorisations (système de fichiers racine) ne sont pas modifiées? Doit être root:rootcomme les deux lignes ci-dessous:

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

Si le propriétaire est un autre utilisateur (et non root), cela empêchera la création de tous les fichiers temporaires par systemd lors du démarrage du système. Vous pouvez également vérifier avec la commande:

systemd-tmpfiles --create

Si le dossier racine ( /) a une autorisation différente, veuillez le modifier avec la commande suivante:

chown root: /

0

Merci à tous pour les informations utiles. Le problème avec ssh-server sur mon Xenial Lubuntu était en effet lié à la propriété de '/' comme suggéré par Melebius & Stefan.
Créer /var/run/sshdet redémarrer manuellement ssh.service temporairement ssh-server temporairement. Modification dusshd.conf n'a pas aidé dans ce système. Ensuite, après la dernière suggestion, j'ai vérifié la propriété du dossier racine avec:

' ls -alF /' et bien sûr, il a été accidentellement changé en utilisateur / groupe local. Émission à partir du terminal: ' sudo chown root:root /' a corrigé mon système, quelle que soit la modification vers sshd.conf. J'ai donc restauré cela à son état d'origine, à savoir d /var/run/sshd 0755 root root.


0

Je rencontre ce problème sur ma machine lorsque j'exécute plusieurs instances de sshd sur une seule machine (18.04.02 LTS, OpenSSH 7.6p1).

Le problème est qu'il n'y a aucun commutateur dans sshd (c'est-à-dire la ligne de commande ou le sshd_configfichier) prévu pour changer l'emplacement du "répertoire de séparation des privilèges". Le répertoire doit être dans le /var/empty, selon le code source d'OpenSSH 7.6p1.

Le package Ubuntu a remappé cela à /run/sshd .

Il existe un problème de «sécurité des threads» dans les init.dscripts au démarrage lorsque les deux scripts de service tentent de créer le répertoire. J'ai demandé à Ubuntu et à OpenSSH de résoudre le problème des noms de chemin codés en dur "répertoire de séparation des privilèges" dans sshd. Si je pouvais télécharger des fichiers, j'ai le fixe basé sur le code source OpenSSH 8.0p1.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.