☰

Beschreibung des Zustands

tag-icon • tag-icon ssh systemd sshd systemd-unit
Beschreibung des Zustands

Beschreibung des Zustands

Ich bin auf einen seltsamen Zustand mit systemd und ssh unter Ubuntu 18.04.3 LTS gestoßen

Ich habe den Status des ssh.socketGeräts überprüft:

$ systemctl status ssh.socket
● ssh.socket - OpenBSD Secure Shell server socket
   Loaded: loaded (/lib/systemd/system/ssh.socket; disabled; vendor preset: enabled)
   Active: inactive (dead)
   Listen: [::]:22 (Stream)
 Accepted: 0; Connected: 0

Und es war inaktiv, jedoch war ich zur selben Zeit mit SSH angemeldet und der Dienst selbst lief und der SSH-Socket und der entsprechende Port waren geöffnet:

$ lsof -P -i -n | grep sshd
sshd      26785            root    3u  IPv4 14858764      0t0  TCP 10.200.130.28:22->10.100.40.141:42188 (ESTABLISHED)
sshd      26875          xxx_root    3u  IPv4 14858764      0t0  TCP 10.200.130.28:22->10.100.40.141:42188 (ESTABLISHED)
sshd      63859            root    3u  IPv4   238437      0t0  TCP *:22 (LISTEN)
sshd      63859            root    4u  IPv6   238439      0t0  TCP *:22 (LISTEN)

Also habe ich mir die Unit-Datei von ssh.socket unter folgendem Pfad angesehen /lib/systemd/system/ssh.socket:

[Unit]
Description=OpenBSD Secure Shell server socket
Before=ssh.service
Conflicts=ssh.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

Aufgrund der Before=ssh.serviceDirektive sollte es vor dem SSH-Dienst gestartet werden, und die Conflicts=ssh.serviceDirektive bewirkt, dass es gestoppt wird, wenn der SSH-Dienst startet.

Das erklärt, warum dies im Hinblick auf die Unit-Dateien geschieht, wirft aber andere Fragen auf.

Fragen

Warum hat der inaktive Zustand der ssh.socket-Einheit keine Auswirkung auf den eigentlichen SSH-Socket?

Warum haben die Betreuer die ConflictDirektive hinzugefügt? Wenn Sie beispielsweise die Unit-Datei überprüfen, docker.socketist sie nicht so eingestellt, dass sie mit der in Konflikt steht docker.service. Wie unterscheidet sich der Fall von sshd?

zusätzliche Information

Ich habe dies auch auf einer alten Fedora 30-Workstation überprüft. Es liegt derselbe Zustand vor, mit geringfügigen Unterschieden: Es verwendet sshd.serviceund sshd.socketals Unit-Namen und es gibt keine BeforeDirektive in der sshd.socketUnit-Datei.

Auf beiden Systemen konnte ich keine aus diesem Zustand resultierenden Probleme feststellen und ich vermute, dass es einen Grund dafür gibt, kann jedoch keinen finden.

Antwort1

Ein systemd-Socket ist ein spezieller Einheitentyp, der systemd veranlasst, sich selbst an den Port (oder eine andere Ressource, wie etwa einen Unix-Domain-Socket-Dateipfad) zu binden und für jede Verbindung eine neue Instanz eines Dienstes zu erzeugen. Wenn ssh.service aktiviert ist, läuft sshd kontinuierlich und bindet sich an den Socket, wie Ihr lsof zeigt. Wenn ssh.socket stattdessen aktiviert ist, würde das bedeuten, dass sshd nicht kontinuierlich läuft, sondern eine Instanz davon nur aufgerufen wird, um den einen Client zu handhaben. Und im Gegensatz dazu würde es zeigen, dass systemd auf Port 22 lauscht. Da systemd und sshd nicht beide auf demselben Port lauschen können, gibt ssh.socket ssh.service als in Konflikt stehend an.

Antwort2

Wichtig zu verstehen ist, dass es sich hier um eine spezielle Verwendung von „Socket“-Einheiten handelt. Insgesamt gibt esdrei:http://0pointer.de/blog/projects/inetd.html

Im speziellen Fall von ssh.socketist dies das Äquivalent von altem Stilinetd-ähnlicher Aufruf(Core Socket Unit Setting: Accept=yes), wobei jede eingehende Anfrage auf Port 22 (verwaltet von systemd) den Start eines separaten[email protected] Beispiel.

Siehe auch die Manpage von systemd.socket:https://www.freedesktop.org/software/systemd/man/systemd.socket.html

Wenn Accept=yes gesetzt ist, wird eine Servicevorlage[email geschützt]muss vorhanden sein, von wo aus Dienste für jede eingehende Verbindung instanziiert werden

Es gibt also insgesamt zwei verschiedene Möglichkeiten, sshd zu starten:

  • ssh.service( sshd.serviceist nur ein Alias) startet den Haupt-SSHD-Prozess und von dort an verarbeitet der Prozess alle eingehenden Verbindungen, erzeugt untergeordnete Prozesse usw. usw.
  • ssh.socket+ [email protected], hier verbindet systemd jede eingehende Verbindung vom Socket-verwalteten Port mit einer neuen Instanz von[email geschützt], im inetd-Stil. Aus diesem Grund verfügt der Vorlagendienst über die Option , StandardInput=socketund .ExecStart=/usr/sbin/sshd-i

Natürlich kann immer nur ein Ansatz gleichzeitig verwendet werden. Stellen Sie daher Conflicts=sicher, dass nicht beide gleichzeitig ausgeführt werden. (Übrigens: Die tatsächliche Platzierung der Conflicts=Strophe ist nicht wichtig. Eine entsprechende Strophe hätte in ssh.service geschrieben werden können, aber eine reicht aus.)

verwandte Informationen