[SOLVED] sshd startet vor den Interfaces

[whiizy]

Bin gerade etwas genervt, weil der openssh-server bzw. sshd mir gerade unerwartete Probleme macht. Baue gerade eine temporäre Bedienstation auf einem Laptop mit Debian Bookworm. Die Kiste hat zwei Interfaces in zwei unterschiedlichen Netzen. Beide Interfaces antworten und alle Routen funktionieren, wie es sein soll.

Per default lauscht der sshd auf allen Interfaces (0.0.0.0) und ich kann auf allen per ssh connecten. Verwaltet werden sie mit networkmanager bzw. dessen KDE plasma applet auf dem Dektop und die ganze Geschichte ist boot-fest.

Aus Sicherheitsgründen wollte ich den sshd jetzt aber nur auf einem der beiden Interfaces lauschen lassen. Also explizit die ListenAddress in der sshd_config gesetzt. Die meisten hier würden es vermutlich auch so angehen. Große Überraschung aber dann: Der sshd kommt nach dem Booten nicht hoch! Die Interfaces antworten zwar auf ping, aber der sshd setzt nicht darauf auf und beendet sich

Wenn ich mich in diesem Zustand auf dem desktop einlogge und 'systemctl start ssh' eingebe, startet der sshd aber wunschgemäß auf meiner expliziten ListenAddress.

Das Journal von systemd legt nahe, daß der sshd zum Zeitpunkt in der Boot-Sequenz die IP-Adressen noch nicht rechtzeitig zur Verfügung hat. Das verstört mich allerdings etwas, da ich dachte die Abhängigkeiten würden von systemd so praxisgerecht verwaltet, daß sshd auf die IP-Adressen lang genug wartet.

Das eine Interface ist das eth des Laptops mit einer DHCP-Adresse und das andere ein USB-to-ETH-Adapter mit statischer IP. Ist natürlich nicht der absolute Standardfall, aber sshd läuft wie gesagt ohne Probleme auf beiden IP's - wenn sie zum Start des sshd schon existieren.

Das automatische Beenden des sshd beim Boot kann ich immerhin noch verhindern, indem ich eine der ListenAddresse(s) auf 127.0.0.1 setze. Dann findet der sshd zumindest diese eine beim Boot, hängt sich drauf und beendet sich deshalb nicht.

Frage:
Muß ich mich jetzt etwa tief in die Unit files von systemd reinknien, nur um einen provisorischen Openssh-Server mit ListenAdress auf einem Laptop an's Rennen zu kriegen??

Seid ihr darüber vielleicht auch vor Bookworm schonmal gestolpert? Hat es sich dann anders lösen lassen, als den sshd global auf allen Interfaces (0.0.0.0) lauschen zu lassen?

VG

[mat6937]

Seid ihr darüber vielleicht auch vor Bookworm schonmal gestolpert? Hat es sich dann anders lösen lassen, als den sshd global auf allen Interfaces (0.0.0.0) lauschen zu lassen?

Ja und ja. Mit:

Code: Alles auswählen

net.ipv4.ip_nonlocal_bind = 1
net.ipv6.ip_nonlocal_bind = 1

in der /etc/sysctl.conf (oder gleichwertige Datei) und rebooten.

[JTH]

Auf anderem Wege könnte ein

Code: Alles auswählen

# systemctl enable NetworkManager-wait-online.service
# systemctl edit ssh.service

und bei letzterem eingefügtes

Code: Alles auswählen

[Unit]
After=network-online.target
Wants=network-online.target

zum Ziel führen. Nicht ausprobiert für diesen konkreten Anwendungsfall.

[mat6937]

Auf anderem Wege könnte ein

Code: Alles auswählen

# systemctl edit ssh.service

Dann besser mit einer drop-in-Datei, die service-unit aufhübschen. Bei einem update wird die native service-unit geändert.

[JTH]

Dann besser mit einer drop-in-Datei, die service-unit aufhübschen. Bei einem update wird die native service-unit geändert.

Na, systemctl edit tut doch genau das. Es legt eine override.conf genannte drop-in-Datei an, ohne dass man von Hand erst den foobar.service.d-Ordner anlegen muss. Gleichzeitig zeigt es dir im Editor auskommentiert alle aktuell gesetzten Optionen für den Service/die Unit an. Und sorgt auch für das notwendige systemctl daemon-reload. Super praktisch, so was macht man doch nicht mehr von Hand

edit UNIT...
Edit a drop-in snippet or a whole replacement file if --full is specified, to extend or override the specified unit.

Schnell wieder löschen kann man drop-ins übrigens mit systemctl revert UNIT.


Noch eine Alternative zur Eingangsfrage, die sich auch auf systemd stützt:
Benutz das ssh.socket zusätzlich zu sshd_configs ListenAddress dafür, dass sshd nur im gewünschten Netz startet:
In

Code: Alles auswählen

# systemctl edit ssh.socket

Folgendes einfügen

Code: Alles auswählen

[Socket]
ListenStream=1.2.3.4:22

und anschließend auf das Socket „umsteigen“

Code: Alles auswählen

# systemctl enable --now ssh.socket
# systemctl disable --now ssh.service

[mat6937]

Es legt eine override.conf genannte drop-in-Datei an, ... Super praktisch, so was macht man doch nicht mehr von Hand

Wird mit edit immer nur eine drop-in-Datei, mit dem Namen override.conf, angelegt?

[whiizy]

Schonmal ein Wow! zwischendurch für die tollen Tips Werde ich morgen gleich ausprobieren.

[JTH]

Wird mit edit immer nur eine drop-in-Datei, mit dem Namen override.conf, angelegt?

Ohne weitere Optionen, also bei systemctl edit foobar.service, wird immer /etc/systemd/system/foobar.service.d/override.conf angelegt, ja. Einen anderen Namen kann man meines Wissens nicht angeben, man bearbeitet mit dem edit also immer dieselbe Datei pro Unit. Das ganze geht natürlich auch für .socket, .timer, .network etc. und globale User-Units.

Von --full hab ich vorhin das erste Mal gelesen. Da wird systemctl edit --full foobar.service wohl /etc/systemd/system/foobar.service erzeugen.

Probiers einfach mal aus, kann man ja alles leicht rückgängig machen (oder gar nicht erst speichern, nur mal in den Editor gucken)


Ergänzung:
Ab systemd 253, aktuell in sid, kann man per --drop-in den Namen angeben:

* New option '--drop-in=' can be used to tell 'systemctl edit' the name of the drop-in to edit. (Previously, 'override.conf' was always used.)

[whiizy]

JTH, dein Weg über ein systemd "drop-in" funktioniert wunderbar, vielen Dank!

Zusammengefasst musste ich nur ...

Code: Alles auswählen

# systemctl edit ssh.service

...aufrufen und ...

Code: Alles auswählen

[Unit]
After=network-online.target
Wants=network-online.target

... einfügen und abspeichern.

Das erzeugte drop-in liegt danach als override.conf im Pfad /etc/systemd/system/ssh.service.d/

Den NetworkManager-wait-online.service musste ich nicht anpacken, der war bereits per default enabled.

Der sshd wartet jetzt beim boot darauf, daß die ListenAddress wirklich online ist. Ziel erreicht!

Das Problem war vorher wohl, daß der sshd bereits beim Erreichen des network connects startete, aber die IP zu dem Zeitpunkt noch nicht anlag.

Danke für eure sehr guten Beiträge!

[mat6937]

Das Problem war vorher wohl, daß der sshd bereits beim Erreichen des network connects startete, aber die IP zu dem Zeitpunkt noch nicht anlag.

Ja.

Aber mit z. B.:

Code: Alles auswählen

net.ipv4.ip_nonlocal_bind = 1

(siehe oben) machst Du die Änderung/Konfiguration für _alle_ lauschenden Dienste (... nicht nur für den sshd) und das auch für IPv4-Adressen die es (noch) gar nicht gibt bzw. dem Interface nicht oder noch gar nicht zugewiesen sind.

[whiizy]

Hallo mat6937,

ich habe deinen Lösungsvorschlag jetzt auch noch durchgespielt. Hier mit einer gleichwertigen Include-Datei /etc/sysctl.d/local.conf und dem Inhalt:

Code: Alles auswählen

net.ipv4.ip_nonlocal_bind = 1

Löst das Problem auf meinem Laptop ebenso!

Bin mir aber über mögliche Seiteneffekte dieses globalen Kernel-Schalters nicht im Klaren, daher belasse ich es zunächst bei der Insellösung für den sshd über das systemd drop-in.

Sollte ich auf dem Laptop später noch einen anderen Dienst als SSH anbieten und auf ähnliche Probleme stoßen, werde ich mich an deine Methode erinnern. Zunächst ist erstmal nur ein VNC-Server als weiterer Service geplant, aber der wird vermutlich sowieso nur vom mir auf localhost 127.0.0.1 betrieben werden und vermutlich auch nur von Hand bedarfsweise gestartet -- und dann wären die lokalen IP(s) ja längst UP.

Danke nochmal für deine Ergänzung!

[JTH]

(Ich will hier nicht so klingen, als ob ich „meine“ Lösung verteidigen will. Alles hat pro und contra )

Code: Alles auswählen

net.ipv4.ip_nonlocal_bind = 1

(siehe oben) machst Du die Änderung/Konfiguration für _alle_ lauschenden Dienste (... nicht nur für den sshd)

Ein Schwachpunkt, der mir dazu einfällt, ist, dass man auf dem Weg gar nicht mehr mitbekommt, wenn man irgendwo mal eine falsche, nie existierende IP zum Lauschen konfiguriert. Jegliche Anwendung würde sich fröhlich an diese binden.

Die beiden Zeilen, die für die Abhängigkeit zu network-online.target sorgen, muss man nicht bei allen Diensten ergänzen. Es gibt auch Units, die diese Abhängigkeit schon von Haus aus mitbringen.

und das auch für IPv4-Adressen die es (noch) gar nicht gibt bzw. dem Interface nicht oder noch gar nicht zugewiesen sind.

Ja, das dürfte ein Schwachpunkt des network-online.target sein. Wenn man das Netz wechselt oder erst später, nach dem Systemstart aktiviert/konfiguriert, ist whiizy vermutlich wieder bei seinem Ausgangsproblem.

[mat6937]

Ein Schwachpunkt, der mir dazu einfällt, ist, dass man auf dem Weg gar nicht mehr mitbekommt, wenn man irgendwo mal eine falsche, nie existierende IP zum Lauschen konfiguriert. Jegliche Anwendung würde sich fröhlich an diese binden.

Nein, das "binden jeglicher Anwendung" an diese IP-Adresse kann nicht passieren, denn die nicht existierende IP-Adresse ist ja keinem Interface zugewiesen, sondern nur in der config einer bestimmten Anwendung (hier sshd) eingetragen. Ich wollte damit nur zeigen, dass "ip_nonlocal_bind = 1" den sshd auch dann _starten lässt_, wenn in seiner config nur eine einzige (wirksame) IP-Adresse eingetragen ist, die _keinem Interface zugewiesen_ ist:

Code: Alles auswählen

sshd -t
(keine Ausgabe)

Code: Alles auswählen

:~# cat /etc/ssh/sshd_config.d/my_sshd_config.conf | grep -i listen
#ListenAddress 192.168.178.13:#####
#ListenAddress 192.168.178.13:#####
#ListenAddress 192.168.174.24:#####
ListenAddress 192.168.175.24:22222

Code: Alles auswählen

:~# ip a | grep -i 192.168.17
    inet 192.168.178.13/24 brd 192.168.178.255 scope global eth0
    inet 192.168.174.24/24 brd 192.168.174.255 scope global eth0

Code: Alles auswählen

:~# lsof -nPi | grep -i ssh
sshd      496            root    3u  IPv4  12229      0t0  TCP 192.168.175.24:22222 (LISTEN)