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


23

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 danach konnte ich über ssh keine Verbindung zum Server herstellen. Die Meldung, die ich erhalten habe, lautet:

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

Also öffnete ich eine serielle Konsole auf dem VPS und begann zu untersuchen ... Ich habe die gelöscht und openssh-serverohne Erfolg neu installiert . Ich habe zwei Stunden damit verbracht, Artikel, Fragen und Antworten zu ähnlichen Themen im Internet zu lesen.

Schließlich habe ich verstanden, dass das Verzeichnis /var/run/sshdwährend des Systemstarts nicht erstellt wird. Und 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 /var/run/sshdwird beim Systemstart 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? Sollte ich den Hosting-Anbieter bitten, das Problem zu lösen?


Der Ausgang von systemctl status ssh.service, sshd -Ddp 22und journalctl -xeist:

# 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.confund /etc/init/ssh.confist:

# 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/runes sich um einen symbolischen Link handelt /run, ich weiß nicht, warum dies erforderlich ist, aber als ich den Inhalt der Datei änderte, /usr/lib/tmpfiles.d/sshd.confvon:

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.


Dieses Problem kann plötzlich nach einem Neustart aufgrund eines Versions-Upgrades auftreten, das unmittelbar vor diesem Neustart durchgeführt wurde, wie in dieser verknüpften Frage beschrieben . Die Lektion: Aktualisieren Sie nicht, es sei denn, Sie sind sicher, dass Ihr Kernel dies unterstützt.
Schnee

Antworten:


24

Ich habe festgestellt, 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 auf dem Launchpad zu sehen ist: Fehler # 45234 , Fehler # 1811580 ; oder bei ServerFault: Warum fehlt / var / run / sshd nach jedem Start?

Es gibt nur wenige Problemumgehungen für dieses Problem. Sie können alle auf alternative Weise erstellt werden, /var/run/sshdbevor der SSH-Server ausgeführt wird. Hier sind drei mögliche Lösungen.


Problemumgehung 1: Ändern /usr/lib/tmpfiles.d/sshd.confauf folgende Weise:

d /run/sshd 0755 root root

Wie in der Frage erwähnt, /var/runhandelt es sich um einen symbolischen Link /run, dessen Endergebnis identisch ist: /var/run/sshderstellt wird. Ich weiß nicht warum, aber das funktioniert.


Problemumgehung 2: Verwenden Sie einen Cron-Job, der /var/run/sshdden SSH-Server erstellt und neu startet. Sie können die Rootscrontab für diesen Zweck verwenden. Führen sudo crontab -eSie den folgenden Eintrag aus und fügen Sie ihn 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: Gehen Sie /etc/rc.localwie oben beschrieben vor, wie in diesem Kommentar zum Fehlerbericht Nr. 45234 gezeigt.


1
Danke, das behebt ssh, aber nicht die allgemeineren Probleme, wenn systemd kaputt geht. Versuchen Sie, systemd-tmpfiles --create auszuführen, und sehen Sie alle Fehler
paulzag

1
Sie haben recht, @paulzag, aber in meinem Fall bin ich sicher, dass das allgemeine Problem der alte Kernel ist. Ich habe mich entschlossen, diese angezeigten Fehler zu ignorieren systemd-tmpfiles --create, da im Moment keine vernünftigen Fehlfunktionen auf dem Server vorliegen Die aktuelle Frage ist, wie der SSH-Dienst nach dem Neustart in Betrieb genommen werden kann, während das Problem behoben ist. Wenn Sie möchten, können Sie die Lösung
verbessern

Der "Workaround 1" funktionierte für mich ... Danke ... Up Voted ...
Biswadeep Sarkar

2
Es wäre sinnvoller, sie zu überschreiben, /usr/lib/tmpfiles.d/sshd.conf anstatt sie direkt zu ändern, da diese Datei vom Paketmanager verwaltet wird. Nehmen Sie dazu einfach die Änderung in vor /etc/tmpfiles.d/sshd.conf. dies hat Vorrang vor dem sshd.confin /usr/lib. Siehe diesen Abschnitt in tmpfiles.d (5) .
Ungeachtet der Tatsache

1
In Bezug auf , warum Umgehung 1 arbeitet; Sie vermeiden die Verwendung des /var/runSymlinks, systemd-tmpfilesmit dem ein Problem besteht und warum das PrivSep-Verzeichnis nicht erstellt wird. Die viertletzte Nachricht dieses Threads gibt Aufschluss darüber. Zugegeben, es systemd-tmpfiles-cleanbetrifft, aber ich habe das Gefühl, dass hier das Gleiche gilt.
ZeroKnight

1

Könnten Sie überprüfen, ob Ihre /(Root-Dateisystem-) Berechtigungen nicht geändert wurden? Müssen root:rootwie die beiden folgenden Zeilen sein:

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

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

systemd-tmpfiles --create

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

chown root: /

0

Vielen Dank an alle für hilfreiche Informationen. Das Problem mit ssh-server auf meinem Xenial Lubuntu hing in der Tat mit dem Besitz von '/' zusammen, wie von Melebius & Stefan vorgeschlagen. Ssh.service vorübergehend
manuell erstellen /var/run/sshdund neu starten ssh-server vorübergehend. Das bearbeiten sshd.confhat in diesem System nicht geholfen. Dann habe ich nach dem letzten Vorschlag den Besitz des Stammordners überprüft mit:

' ls -alF /' und sicher genug, es wurde versehentlich in einen lokalen Benutzer / eine lokale Gruppe geändert. Ausgabe vom Terminal: ' sudo chown root:root /' mein System repariert, unabhängig von der Bearbeitung auf sshd.conf. Also habe ich den ursprünglichen Zustand wiederhergestellt, d d /var/run/sshd 0755 root root. H.


0

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 ist, dass in sshd (dh in der Befehlszeile oder in der sshd_configDatei) keine Schalter zum Ändern des Speicherorts des "Verzeichnisses für die Trennung von Berechtigungen" vorgesehen sind. Das Verzeichnis sollte sich /var/emptylaut OpenSSH 7.6p1 im Quellcode befinden.

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

Es gibt ein "Thread-Sicherheitsproblem" in den init.dSkripten beim Booten, wenn beide Dienstskripte versuchen, das Verzeichnis zu erstellen. Ich habe Ubuntu und OpenSSH gebeten, das Problem der fest codierten Pfadnamen für "Privileg Separation Directory" in sshd anzugehen. Wenn ich Dateien hochladen könnte, hätte ich den auf 8.0p1 basierenden OpenSSH-Quellcode behoben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.