Die Metapher „In Teufelsküche kommen“ kennt Ihr vermutlich. Etwas, daß ich nach den Fedora 43 Updates auch noch festgestellt habe war, daß systemd beim Booten folgende Meldung anzeigen lies:

Try contacting this VM's SSH server via 'ssh vsock%1' from host.

Jetzt denkt Ihr Euch natürlich sofort: „Was verflucht meint das?“  Es meint die oben genannte Küche.

Erstmal zur Erklärung: Was sind VSOCKets ?

Wie andere UNIX SOCKETS auch, handelt sich erst einmal um normales Socket, das als Kommunikationskanal zwischen Anwendung A und B dient. Im krassen Unterschied zu einem normalen Socket innerhalb eines PC oder VM, baut sich über ein VSOCK eine direkte, unsichtbare „Standleitung“ zwischen dem Host und einer VM auf. 

Wenn mal also einen Xen, VMWare oder eine Proxmox Server betreibt, kann man vom eigentlichen Serversystem direkt per SSH in die VM einloggen, vorbei an allen Firewalls, Netzwerkeinstellungen und Sicherheitsrichtlinien. Was als feuchter Traum eines VMWare Admins begonnen haben dürfte, weitet sich schnell zu einem gravierenden rechtlichen Problem aus, wenn der Serverbereiber die VM an einen Kunden vermietet, also nicht selbst die VM betreibt.

Die Bedrohungslage ändert sich mit dem Tunnel unter der Firewall

Durch die reine Bereitstellung des VSOCKets in der VM,hat sich die Bedrohungslage komplett geändert. Was vorher getrennt war, ist jetzt verbunden und zwar ohne die Möglichkeit es zu blocken. Fairerweise muß man sagen, daß auch eine VSOCK Verbindung zum SSHD Authorisierung braucht. Einfach so einloggen ist nicht.

Normale SSH Server haben wegen der ganzen Bruteforceattacken entweder Fail2BAN oder NIDS Systeme laufen, die Bruteforce-Angriffe erkennen und im Falle eines Angriffes die Angreifer-IP Blocken. Bei einem VSOCK Connect gib es keine IP die man blocken könnte, man müßte das Socket abschalten.  Einen Brute-Force stoppen kann daher schwer werden und da kommt Malware ins Spiel [1]. Es wäre also möglich, einen Server zu hacken, und sich dann per VSOCK und BruteForce in die VM rein zuhacken., ohne das jemand was merkt.

Selbst wenn wir das mal außer Acht lassen und annehmen, daß der Serverbetreiber in die VM einloggt, könnte es zu einer Straftat werden. Wenn der Serverbetreiber keinen Zugriff mit dem Kunden vereinbar hat, um z.B. Software zu managen, dann stellt der Login in das System einen unbefugten Zugriff dar, der nach §202a StGB strafbar ist. Das wäre er auch, wenn er übers Netzwerk käme. Der Umstand, das der Serverbetreiber einfach die Platte der VM so mounten könnte um an die Daten zu gelangen, ist lediglich eine Variante des Zugriffs.

Könnte ein Systemd Entwickler dafür belangt werden?

Die Frage habe ich Gemini gestellt und der meinte, der Hoster müßten jedes Changelog jeder eingesetzten Software auf Änderungen überwachen, die die Systemintegrität beeinflussen könnten und in den stände das mit dem VSOCK drin, damit wärs nicht mehr heimlich und somit nicht strafbar. Soviel zur künstlichen Intelligenz, denn die natürliche Intelligenz hat das unter „faktische Unmöglichkeit“ ausgeschlossen, da das nicht mal theoretisch leistbar ist, was man an der nicht-leistung der „künstlichen Intelligenz“ gesehen hat, die folglich auch nicht in der Lage wäre diesen Job zu leisten

Wenn der Kunde die VM mit Memoryencryption und Full-Disk-Encryption schützt, wäre ein heimlicher Zugriff per VSOCK eine nette Möglichkeit um doch an die Daten zu gelangen, z.b. weil Strafverfolgungsbehörden das so angeordnet haben ( EU Antiterror Gesetz)[übrigens ein Umstand für den das Systemdteam einen auf Github blockt, wagt man das scherzhaft zu erwähnen 😉 ][2]. Etwas, daß nicht möglich wäre, wenn man das gar nicht erst starten würde und damit kommen wir zum eigentlichen Punkt:

Systemd startet das SSHD Vsocket nach der installation automatisch.

Ein Umstand der Admins natürlich Kopfschmerzen und Herzrasen verursacht, weil sich da ungefragt etwas an Ihren Sicherheitseinstellungen vorbei mogeln will. Ums kurz zu machen, so werdet Ihr das los:

systemctl disable –now sshd-vsock.socket
systemctl mask sshd-vsock.socket

Da stellt sich natürlich die Fragen, wieso das automatisch aktiviert ausgeliefert wird, statt es deaktiviert auszuliefern. Es ist ja eine nicht ganz unerhebliche Änderung am System, wenn ich da ein Loch durch alle Firewalls bohre und es dem Admin dann erst beim Boot mitteile, oder wusste Einer von Euch das schon vor meinem Artikel? Die Anzahl an „Ja“s wird sich wohl in Grenzen halten.

IMHO 

Ist das weder guter Stil noch genial durchdacht worden, zumal sich rausstellte, daß z.b. ProxMox keinen Plan hat, wie es zu dem VSOCK der VM verbinden soll, ergo der Dienst überflüssig war. Ich kann mir vorstellen, daß wenn man selbst Container und VM auf einem Server betreibt, es ok ist, wenn es funktionieren würde, obwohl ich kein Dockerimage mit SSH Zugang gefunden habe. ( nicht, das ich intensiv danach suchen würde 😉 )

Aber mal ehrlich: Spart es wirklich Zeit ein? Eher nicht, weil die VM vorher ja schon erreichbar sein mußte per SSH und das über Jahre und Jahrzehnte. Ergo ist der Workflow alt eingefahren und kommt ohne Vsock aus. Einzig die Verteilung von Datenpaketen über mehrere VM könnte mangels Netzwerklimit etwas schneller gehen, aber auch nicht wirklich, weil man es ja auch erstmal auf den Host holen muß, um es dann weiter zu verteilen. Da braucht es schon GB große Datenmengen, damit sich das lohnt.

Wäre das deaktiviert ausgeliefert worden, wärs mir egal gewesen, aber so, mußte ich was sagen.

[1] https://seclists.org/oss-sec/2025/q4/298

[2] https://github.com/systemd/systemd/issues/39640