Warum fehlt mir nach jedem Start / var / run / sshd?

12

Ich verwende einen Ubuntu 16.04-Container unter Proxmox 5.2-11. Nach dem Anwenden der letzten Patch-Runde 1 kann ich mich nicht an der Konsole oder über ssh anmelden.

I angebracht , um den Behälter root FS auf dem Hypervisor und hinzugefügt pts/0zu /etc/security/access.conf(wir laufen pam_access) und das erlaubt Root - Anmeldung an die Konsole. Wir haben, root : lxc/tty0 lxc/tty1 lxc/tty2in access.confdenen ich dachte, es sei ausreichend, warum ich es pts/0jetzt brauche, ist rätselhaft.

Ich bemerkte, dass ssh nicht lief, also versuchte ich es von Hand zu starten ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) und erhielt diesen Fehler:

Missing privilege separation directory: /var/run/sshd

Ich habe das Verzeichnis von Hand erstellt, gestartet sshund konnte mich endlich anmelden, aber nach einem Neustart bleibt das Problem bestehen. Das Verzeichnis wird nicht erstellt. Nur nützliche journalctlTeile und der einzig interessante Teil ist etwas über "Betrieb nicht erlaubt", aber keine weiteren Informationen.

Ich bin mit 16.04 nicht allzu vertraut und frage mich, wie ich mehr über das Problem herausfinden kann. Ich habe keine /var/log/syslogoder /var/log/messagesnur kern.logso etwas verloren.

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

systemd-tmpfiles --createAusgabe hinzugefügt

Wirklich bizarr ... Ich habe nachgesehen /tmpund diese Dateien existieren nicht

— Serverfehler
quelle

11

Ein Fehler, den Sie gemacht haben, war der Versuch, sshdvon Hand zu beginnen .

Wenn Sie stattdessen mit sshdoffiziellen Mitteln beginnen, sollte es einfach funktionieren. Der serviceBefehl weiß, wie ein Dienst auf Ihrer Distribution richtig gestartet wird, und dies sollte funktionieren:

service ssh start

Bei Sysv-Init-Skripten ist dies alles, was Sie tun müssen. Der Grund, warum das Verzeichnis fehlt, ist, dass /var/runes ein Symlink zu /runund /runein tmpfsMountpunkt ist. Das bedeutet, dass bei jedem /var/runStart leer anfängt. Wenn Sie den serviceBefehl verwenden, wird das /etc/init.d/sshSkript zum Starten verwendet. sshdZuvor wird das Skript jedoch erstellt, /var/run/sshdwenn es nicht vorhanden ist.

Mit systemdDingen etwas anders arbeiten. Es wird eine Datei /usr/lib/tmpfiles.d/sshd.confmit diesem Inhalt aufgerufen :

d /var/run/sshd 0755 root root

Während des Startvorgangs sollte das /var/run/sshdVerzeichnis erstellt werden. Was Sie benötigen, um zu überprüfen, ob die Datei vorhanden ist und den richtigen Inhalt hat. Wenn das /var/run/sshdVerzeichnis noch fehlt, können Sie überprüfen, ob es beim systemd-tmpfiles --createmanuellen Ausführen erstellt wird.

— Kasperd
quelle

Das ist eine gute Idee, macht aber im Wesentlichen dasselbe, was das System beim Booten versucht hat (und auf die gleiche Weise fehlgeschlagen ist). Was mich wirklich wundert, ist, warum das privsep-Verzeichnis nicht mit normalen Mitteln erstellt wird. Gibt es einen Festplattenfehler? Ein Berechtigungsproblem? Datei sperren? Wo sonst noch zu suchen journalctl?

— Server Fehler

@ServerFault Wird unter bestimmten Umständen /etc/init.d/sshnicht ausgeführt und systemctlstattdessen verwendet. Und wann sshdüber systemctldas Verzeichnis gestartet wird, wird nicht erstellt. Das lässt ein paar offene Fragen offen, die ich morgen untersuchen werde, z. B. was sich genau geändert hat und wie genau dieses Verzeichnis erstellt werden soll, wenn systemctles verwendet wird.

— Kasperd

@ServerFault Bei Verwendung ist systemctles /etc/init/ssh.conffür die Erstellung des Verzeichnisses verantwortlich. Ich habe auf einem vollständig aktuellen Ubuntu 16.04 getestet und das Verzeichnis wird beim Booten erstellt. Aber aus irgendeinem Grund wird es bei der Verwendung nicht erstellt service ssh start. Es gibt einige aktuelle Updates einiger systemdverwandter Pakete, aber ich sehe keine Hinweise darauf, dass sich das Verhalten bei der Erstellung dieses Verzeichnisses geändert hat. Und wenn ich es teste, wird es beim Booten erstellt. Die Frage ist also, ob Sie /etc/init/ssh.confden richtigen Inhalt haben.

— Kasperd

@ServerFault Ich habe mich vielleicht geirrt, /etc/init/ssh.confdass es auch etwas gibt, /usr/lib/tmpfiles.d/sshd.confdas von verwendet zu werden scheint systemd-tmpfiles --create. Erstellt systemd-tmpfiles --createdas fehlende /var/run/sshdVerzeichnis?

— Kasperd

Bild zur Frage aus der systemd-tmpfiles --createAusgabe hinzugefügt . Die "Symlinks", über die sich systemd beschwert (/tmp/.X11-unix), existieren nicht einmal in, /tmp/daher habe ich keine Ahnung, woher das kommt. Vielen Dank für all Ihre Hilfe, aber ich denke, ich werde weitermachen.

— Server Fehler

10

Daher wird / run (und / var / run, die damit verbunden sind) bei jedem Neustart neu erstellt. Außer dass systemd-tmpfiles dies für einige Dateien, einschließlich (/ var) / run / sshd, nicht tut.

Anscheinend wird dies durch ein OpenVZ-Kernel-Upgrade behoben. Aber um es jetzt tatsächlich zu beheben, bearbeiten /usr/lib/tmpfiles.d/sshd.confund entfernen Sie es /varaus der Zeile d /var/run/sshd 0755 root root, um es stattdessen zu lesen:d /run/sshd 0755 root root

Und das ist es..!

Und wenn openssh-server aktualisiert wird, hoffen wir, dass sie diesen Fehler behoben haben (oder ist es wirklich ein Fehler in systemd? Oder openvz ??) - andernfalls könnten Sie auf dasselbe Problem stoßen.

— pepa65
quelle

1

+1 für das Update, während auf ein Kernel-Upgrade gewartet wird. In meinem Fall musste es werden: "d / run / sshd 0755 root root"

— Paulzag

1

@ Paulzag Das hat auch bei mir funktioniert. Ich frage mich, ob @ pepa65 sagen wollte d /run/sshd 0755 root root, da ihre Anweisungen besagen, nur den /varTeil zu entfernen (obwohl der Code, den sie in der Antwort geben, beides hat /varund /runentfernt hat).

— Stephen Schrauger

4

Anscheinend wird dies behoben, wenn ein OpenVZ-Kernel 2.6.32-042stab134.7 oder neuer ausgeführt wird. Ich finde es seltsam, dass in den systemd-Startskripten irgendwie keine Korrektur möglich ist. Wahrscheinlich würde ein hässlicher Hack wie das automatische Erstellen von / run / sshd / nach dem Start und dem anschließenden Starten von sshd funktionieren.

Die Ausgabe von my 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

Das Änderungsprotokoll von OpenVZ 2.6.32-042stab134.7 lautet wie folgt:

Das Ausführen von Ubuntu-Containern mit systemd 229-4ubuntu21.9 kann dazu führen, dass Dienste nicht gestartet werden, da systemd-tmpfiles den Pfad aufgrund von Symlinking-Problemen nicht überprüfen konnte. (PSBM-90038)

— pepa65
quelle

2

Bei so vielen Problemen, die ich im Laufe der Jahre mit systemd hatte, muss ich zugeben, dass dieses Problem stattdessen auf die Ansible- Synchronisierungsanweisung zurückzuführen ist .

Aus irgendeinem Grund hat dieser Host nach der Bereitstellung unserer Ansbile-Skripte das Verzeichnis / (sowie / etc, / opt und andere) verlassen, das einem Administrator gehört, und nicht root. Nach dem Ausführen chown, um Dinge zu korrigieren, /var/run/sshdwird jetzt beim Booten wieder erstellt.

Ich schätze die gesamte Eingabe sehr, aber hier gibt es keinen Fehler, zumindest in dem Sinne, dass das Anwenden eines unangemessenen Eigentums auf Stammverzeichnisse zu undefiniertem Systemverhalten führte.

— Serverfehler
quelle

Dies! Danke für den Tipp, Ansible war auch in unserem Fall der Schuldige!

— Beenish Khan