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-server
sans 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/sshd
n'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/sshd
n'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 22
et journalctl -xe
est:
# 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.conf
et /etc/init/ssh.conf
est:
# 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/run
s'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.conf
partir 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.
Réponses:
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/sshd
avant d'exécuter le serveur SSH. Voici trois solutions possibles.Solution de contournement 1: modifiez
/usr/lib/tmpfiles.d/sshd.conf
de la manière suivante:Comme il est mentionné dans la question,
/var/run
est un lien symbolique vers/run
, le résultat final est identique:/var/run/sshd
est créé. Je ne sais pas pourquoi, mais cela fonctionne.Solution de contournement 2: utilisez la tâche Cron qui créera
/var/run/sshd
et redémarrera le serveur SSH, vous pouvez utiliser la racinecrontab
à cette fin - exécutezsudo crontab -e
et ajoutez l'entrée suivante:Actuellement, j'utilise cette solution, elle est donc également testée.
Solution de contournement 3: utilisez
/etc/rc.local
pour faire la même chose que ci-dessus, car il est indiqué dans ce commentaire sur le rapport de bogue # 45234.la source
systemd-tmpfiles --create
s'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 :)/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 lesshd.conf
in/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./var/run
lien symbolique, ce quisystemd-tmpfiles
pose 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étantsystemd-tmpfiles-clean
, mais j'ai le sentiment que la même chose s'applique ici.Pourriez-vous vérifier si vos
/
autorisations (système de fichiers racine) ne sont pas modifiées? Doit êtreroot:root
comme les deux lignes ci-dessous: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:
Si le dossier racine (
/
) a une autorisation différente, veuillez le modifier avec la commande suivante:la source
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/sshd
et 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 verssshd.conf
. J'ai donc restauré cela à son état d'origine, à savoird /var/run/sshd 0755 root root
.la source
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_config
fichier) 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.d
scripts 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.la source