webentwicklung-frage-antwort-db.com.de

Der SSH-Server funktioniert nach dem Neustart nicht mehr, da / var / run / sshd fehlt

Mein VPS wurde ungefähr 3 Monate lang nicht neu gestartet. Es wird auf einem Server mit OpenVZ-Virtualisierungstyp gehostet und das Betriebssystem ist Ubuntu 16.04. Aus irgendeinem Grund habe ich den VPS neu gestartet und konnte danach keine Verbindung zum Server über ssh herstellen. Die folgende Nachricht lautet:

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

Also habe ich eine serielle Konsole auf dem VPS geöffnet und mit der Untersuchung begonnen ... Ich habe den openssh-server Ohne Erfolg gelöscht und neu installiert. Ich habe zwei Stunden damit verbracht, Artikel, Fragen und Antworten zu ähnlichen Themen im Internet zu lesen.

Endlich habe ich verstanden, dass das Verzeichnis /var/run/sshd Während des Systemstarts nicht erstellt wird. Sobald ich es manuell erstellt habe, kann ich den SSH-Dienst problemlos starten, aber beim nächsten Neustart bleibt das Problem bestehen . Meine Fragen sind also:

  • Was könnte die Ursache für dieses Problem sein? Warum wird /var/run/sshd Während des Systemstarts nicht erstellt?

  • Wie kann ich das Problem richtig lösen? Ich habe eine zeitliche Lösung gefunden, die am Ende dieses Beitrags erwähnt wird.

  • Kann das Problem mit dem OpenVZ-Host des VPS zusammenhängen? Soll ich den Hosting-Anbieter bitten, es zu lösen?

Die Ausgabe von systemctl status ssh.service, sshd -Ddp 22 Und journalctl -xe Lautet:

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

Der Inhalt von /usr/lib/tmpfiles.d/sshd.conf Und /etc/init/ssh.conf Lautet:

# 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

Zusätzliche Informationen zum System:

# 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

Die zeitliche Lösung : Ich habe festgestellt, dass /var/run Ein symbolischer Link zu /run Ist. Ich weiß nicht, warum dies erforderlich ist, aber als ich den Inhalt der Datei geändert habe /usr/lib/tmpfiles.d/sshd.conf Von:

d /var/run/sshd 0755 root root

zu:

d /run/sshd 0755 root root

beim Systemstart läuft alles gut, der SSH-Dienst wird normal gestartet und ich kann mich über SSH anmelden.

16.04serversshstartupopenvz
23
pa4080

Ich fand, dass dies ein Fehler mit der aktuellen Version von systemd und alten Kerneln ist, die von einigen VPS-Privilegien verwendet werden, wie es in meinem Fall der Fall ist. Dieser Fehler tritt von Zeit zu Zeit auf, wie wir auf dem Launchpad sehen können: Bug # 45234 , Bug # 181158 ; oder auf ServerFault: Warum fehlt mir/var/run/sshd nach jedem Start?

Es gibt nur wenige Problemumgehungen für dieses Problem. Alle bieten eine alternative Möglichkeit, um /var/run/sshd Vor dem Ausführen des SSH-Servers zu erstellen. Hier sind drei mögliche Lösungen.

Problemumgehung 1: Ändern Sie /usr/lib/tmpfiles.d/sshd.conf Wie folgt:

d /run/sshd 0755 root root

Wie in der Frage erwähnt, ist /var/run Eine symbolische Verknüpfung zu /run, Das Endergebnis ist identisch: /var/run/sshd Wird erstellt. Ich weiß nicht warum, aber das funktioniert.

Problemumgehung 2: Verwenden Sie einen Cron-Job, der /var/run/sshd Erstellt und den SSH-Server neu startet. Sie können das crontab des Roots verwenden Führen Sie dazu Sudo crontab -e aus und fügen Sie den folgenden Eintrag hinzu:

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

Derzeit verwende ich diese Lösung, daher wird sie auch getestet.

Problemumgehung 3: Verwenden Sie /etc/rc.local, Um dasselbe wie oben zu tun, wie es ist in diesem Kommentar gezeigt auf Fehlerbericht # 45234.

26
pa4080

Könnten Sie überprüfen, ob Ihr / (Root-Dateisystem) Berechtigungen werden nicht geändert? Muss sein root:root wie die beiden folgenden Zeilen:

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

Wenn der Eigentümer ein anderer Benutzer (und nicht root) ist, wird verhindert, dass während des Systemstarts alle temporären Dateien von systemd erstellt werden. Sie können auch mit dem Befehl überprüfen:

systemd-tmpfiles --create

Wenn der Stammordner (/) hat eine andere Berechtigung, bitte ändern Sie diese mit dem folgenden Befehl:

chown root: /
3
Stefan

Vielen Dank an alle für hilfreiche Informationen. Das Problem mit dem SSH-Server auf meinem Xenial Lubuntu hing tatsächlich mit dem Besitz von '/' zusammen, wie von Melebius & Stefan vorgeschlagen.
Manuelles Erstellen von /var/run/sshd und ssh.service vorübergehend neu starten ssh-server vorübergehend. Bearbeiten der sshd.conf hat in diesem System nicht geholfen. Nach dem letzten Vorschlag überprüfte ich den Besitz des Stammordners mit:

'ls -alF / 'und tatsächlich wurde es versehentlich in einen lokalen Benutzer/eine lokale Gruppe geändert. Ausgabe vom Terminal: 'Sudo chown root:root / 'hat mein System repariert, unabhängig von der Bearbeitung auf sshd.conf. Also habe ich das in seinen ursprünglichen Zustand zurückversetzt, d. H. d /var/run/sshd 0755 root root.

1
Michael

Ich habe dieses Problem auf meinem Computer, wenn ich mehrere Instanzen von sshd auf einem einzelnen Computer ausführe (18.04.02 LTS, OpenSSH 7.6p1).

Das Problem besteht darin, dass in sshd (d. H. Befehlszeile oder in der Datei sshd_config) Keine Schalter zum Ändern des Speicherorts des "Verzeichnis zur Trennung von Berechtigungen" vorgesehen sind. Das Verzeichnis sollte sich gemäß dem OpenSSH 7.6p1-Quellcode im /var/empty Befinden.

Das Ubuntu-Paket hat dies /run/sshd Neu zugeordnet.

Es gibt ein "Thread-Sicherheitsproblem" in den init.d - Skripten beim Booten, wenn beide Dienstskripte versuchen, das Verzeichnis zu erstellen. Ich habe sowohl Ubuntu als auch OpenSSH gebeten, das Problem der fest codierten Pfadnamen für das Verzeichnis zur Trennung von Berechtigungen in sshd zu beheben. Wenn ich Dateien hochladen könnte, habe ich das basierend auf dem 8.0p1 OpenSSH-Quellcode behoben.

0
Luke A Perkins