RustDesk für Linux: Der Open-Source-Remote-Desktop

Linux-Nutzer hatten nie eine große Auswahl an guten Remote-Desktop-Tools, und die wenigen, die es gibt, sind meist entweder Closed-Source-Kommerzprodukte oder in die Jahre gekommene VNC-Stacks. RustDesk positioniert sich anders: Es ist ein Open-Source-Remote-Desktop-Client unter AGPL-Lizenz, läuft nativ auf allen wichtigen Distributionen, und Sie können ihn mit einem selbst gehosteten Server verbinden. Diese Kombination – auditierbarer Code, nativer Linux-Client und selbst hostbare Infrastruktur – macht RustDesk zu einer der ersten Adressen, wenn jemand nach einem Open-Source-Remote-Desktop für Linux fragt.

Dieser Leitfaden zeigt, wie Sie RustDesk installieren, erklärt den einen Punkt, über den alle stolpern (X11 versus Wayland), wie Sie unbeaufsichtigten und Headless-Zugriff zum Laufen bringen, und wo der Server ins Spiel kommt.

RustDesk unter Linux installieren

RustDesk liefert Pakete für jedes gängige Linux-Paketformat, sodass Sie so gut wie nie aus dem Quellcode bauen müssen. Laden Sie die aktuelle Version von der RustDesk-Releases-Seite auf GitHub oder aus der Linux-Installationsdokumentation herunter und wählen Sie das zu Ihrer Distribution passende Format.

Die Pakete .deb und .rpm sind die richtige Wahl, wenn RustDesk als Hintergrunddienst laufen soll, der Neustarts übersteht – beide registrieren und starten automatisch eine systemd-Unit. Das Flatpak (com.rustdesk.RustDesk auf Flathub) ist ein sandboxed Build, der sich gut für den Desktop-Einsatz eignet, aber standardmäßig keinen Systemdienst installiert. Für eine Distribution, die RustDesk nicht direkt paketiert, greifen Sie zuerst zum Flatpak – da es seine eigene Laufzeitumgebung mitbringt, ist es meist am breitesten kompatibel. Das AppImage ist eine portable Einzeldatei-Alternative, deren Kompatibilität in der Praxis aber eher durchwachsen ist (unter aktuellem Ubuntu wird beispielsweise gelegentlich libfuse2 benötigt).

In der Praxis wird RustDesk unter Ubuntu, Debian, Fedora, RHEL/CentOS, openSUSE, Arch und NixOS eingesetzt, mit Builds für x86_64, ARM64 (aarch64) und ARM32 (ARMv7) – es läuft also ebenso auf ARM-Boards und Servern wie auf gewöhnlichen PCs.

X11 vs. Wayland: der entscheidende Punkt

Das ist der wichtigste Punkt, den Sie über RustDesk unter Linux verstehen sollten, denn er entscheidet, ob die Fernsteuerung sofort „einfach funktioniert“ oder erst eine kleine Einstellung braucht.

X11 (Xorg): der direkteste Weg zur Bildschirmerfassung, sofern Ihre Distribution ihn noch anbietet. Unter X11 liest RustDesk den Framebuffer direkt aus und injiziert Eingaben ebenso direkt, sodass Bildschirmerfassung sowie Maus- und Tastatursteuerung so unmittelbar wie möglich ablaufen und Monitoränderungen dynamisch erkannt werden. Viele Display-Manager lassen Sie beim Login über ein Zahnrad-Menü weiterhin „Xorg“/„X11“ auswählen. Bedenken Sie aber, dass mehrere Distributionen zu einem reinen Wayland-Betrieb wechseln und die X11-Sitzung einstellen – behandeln Sie X11 also als praktische Option, wo sie zufällig verfügbar ist, nicht als Grundlage für Ihre Deployment-Planung.

Wayland: RustDesk bietet wohl die stärkste Unterstützung aller Remote-Desktop-Tools. RustDesk unterstützt Wayland seit Version 1.2.0 und baut diese Unterstützung stetig aus. Da Wayland-Compositors keinen direkten Framebuffer-Zugriff erlauben, erfasst RustDesk den Bildschirm über den Dienst xdg-desktop-portal und PipeWire und injiziert Eingaben über das Kernel-Modul uinput. Aus dem Design von Wayland selbst ergeben sich zwei Konsequenzen – sie gelten für jedes Wayland-Screensharing-Tool, nicht nur für RustDesk:

• Zustimmung pro Verbindung. Das Portal zeigt einen Dialog, in dem Sie auswählen, welcher Bildschirm freigegeben wird. Das ist eine bewusste Sicherheitsfunktion von Wayland, kein Fehler von RustDesk – eine Hintergrundanwendung kann nicht klammheimlich die Bildschirmaufnahme starten. Portal v4 und neuer unterstützen ein „Restore Token“, sodass Sie nicht jedes Mal erneut gefragt werden, aber die erste Freigabe erfordert einen Klick auf dem Bildschirm.
• Nur aktive Sitzung. Die Wayland-Erfassung ist an die angemeldete grafische Sitzung gebunden. Die Erfassung des Wayland-Login-Greeters wird noch nicht unterstützt – sie befindet sich in aktiver Entwicklung (PR #15420). Für den Zugriff vor dem Login nutzen Sie derzeit die weiter unten beschriebene Headless-/virtuelle-Display-Konfiguration oder eine X11-Sitzung auf Distributionen, die noch eine anbieten.

Die Wayland-Unterstützung wird laufend verbessert – RustDesk 1.4.3 (Oktober 2025) hat beispielsweise Multi-Monitor-Sharing für Wayland hinzugefügt. Wenn Sie sich jedoch verbinden und auf einem Wayland-System einen schwarzen Bildschirm sehen, liegt das fast immer daran, dass der Portal-/PipeWire-Pfad nicht erfüllt ist. Unser ausführlicher Beitrag RustDesk verbunden, aber wartet auf Bild geht speziell auf den Fall des schwarzen Bildschirms unter Wayland ein.

Unbeaufsichtigter Zugriff unter Linux

Unbeaufsichtigter Zugriff bedeutet, sich mit einem Rechner zu verbinden, vor dem niemand sitzt – das klassische Remote-Support-Szenario. Unter Linux sieht das Rezept so aus:

1. Installieren Sie über .deb oder .rpm, damit der systemd-Dienst registriert wird, oder klicken Sie in der App auf Dienst aktivieren.
2. Legen Sie in RustDesk unter den Verbindungseinstellungen ein starkes dauerhaftes Passwort fest (und aktivieren Sie idealerweise die Zwei-Faktor-Authentifizierung).
3. Für den Zugriff vor oder unabhängig von Benutzeranmeldungen nutzen Sie die weiter unten beschriebene Headless-Konfiguration mit virtuellem Display (die oben erwähnte Lücke beim Wayland-Greeter gilt auch hier).

Eine Wayland-Realität, die Sie einplanen sollten: Das im Wayland-Abschnitt beschriebene zustimmungsbasierte Portal macht eine vollständig unbeaufsichtigte Erfassung schwieriger als unter X11 – zumindest bis die in Entwicklung befindliche Unterstützung für unbeaufsichtigten Zugriff verfügbar ist. Planen Sie deshalb für Rechner ohne Aufsicht mit dem Headless-Setup mit virtuellem Display.

Headless-Linux: Server ohne Monitor

Ein sehr häufiger Linux-Anwendungsfall ist ein Rechner ganz ohne angeschlossenes Display – ein Heimserver, eine Labormaschine, eine VM. Hier liegt das Problem nicht bei RustDesk, sondern beim Grafik-Stack: Ohne angeschlossenen Monitor legen weder X noch Wayland jemals einen Framebuffer an, sodass es buchstäblich kein Bild zu erfassen gibt und Sie einen schwarzen Bildschirm sehen.

Drei Möglichkeiten, ihm etwas zum Rendern zu geben:

• Ein Dummy-Stecker – ein günstiger physischer HDMI-/DisplayPort-„Headless“-Dongle, der die GPU glauben lässt, es sei ein Monitor angeschlossen.
• Ein virtueller Display-Treiber – xserver-xorg-video-dummy unter X11 oder eine Option auf Kernel-Ebene wie VKMS.
• Der optionale Headless-Modus von RustDesk – aktivieren Sie ihn mit sudo rustdesk --option allow-linux-headless Y. Laut dem Wiki zur Headless-Linux-Unterstützung ist er standardmäßig deaktiviert, wird vor allem unter Ubuntu mit GNOME getestet und setzt Pakete wie xserver-xorg-video-dummy und lightdm voraus. Die ID des Rechners können Sie mit sudo rustdesk --get-id abrufen und ein Passwort mit sudo rustdesk --password <password> festlegen.

Der Headless-Modus hat noch Ecken und Kanten – betrachten Sie ihn eher als „funktioniert, mit Sorgfalt“ denn als schlüsselfertige Lösung.

Den RustDesk-Server unter Linux selbst hosten

Alles bisher Beschriebene betrifft den Client. Die andere Hälfte der Linux-Geschichte von RustDesk ist, dass der Server – der hbbs-ID-/Rendezvous-Dienst und das hbbr-Relay – eine Linux-native Anwendung ist und Linux sein natürliches Zuhause ist. Dadurch können Sie Session-Vermittlung und weitergeleiteten Datenverkehr auf Ihrer eigenen Infrastruktur behalten, statt sie über die Cloud eines Anbieters zu leiten.

Sie haben zwei Optionen. Der kostenlose, quelloffene Community-Server läuft unbegrenzt kostenlos und deckt die grundlegende Verbindungs- und Relay-Funktion ab. RustDesk Server Pro ergänzt das um eine selbst gehostete Web-Konsole, Gerätegruppen, ein gemeinsames Adressbuch, einen Generator für individuell gebrandete Clients sowie LDAP/Active Directory und OIDC-SSO. Auch Docker ist keine Pflicht – siehe Server Pro ohne Docker betreiben für eine Installation auf einer gewöhnlichen VM oder Bare-Metal-Hardware. Wenn Sie die Hardware für eine große Flotte dimensionieren, planen Sie die Kapazität anhand Ihres tatsächlichen Gleichzeitigkeits- und Relay-Profils, bevor Sie sich festlegen.

Ein Hinweis zum Self-Hosting: Sowohl der kostenlose Community-Server als auch Server Pro liegen in Ihrer Verantwortung – Betrieb, Patches und Absicherung übernehmen Sie selbst. Die Hardware-Anforderungen sind gering, und ist der Server einmal eingerichtet, ist der laufende Aufwand überschaubar – und bei Fragen hilft der RustDesk-Support. Genau diese Eigenverantwortung ist der springende Punkt. (Die Lizenz von Server Pro benötigt außerdem eine ausgehende Verbindung zu rustdesk.com, um aktiviert zu werden und lizenziert zu bleiben.)

Erste Schritte

Installieren Sie das passende Paket für Ihre Distribution, legen Sie ein dauerhaftes Passwort für den unbeaufsichtigten Zugriff fest, und richten Sie – falls Datenhoheit Ihr Beweggrund ist – den kostenlosen Community-Server ein. Aktuelle Angaben zu den Plänen finden Sie verbindlich unter rustdesk.com/pricing, und [email protected] berät Sie gerne zu Server Pro. Möchten Sie es sich erst in Aktion ansehen? RustDesk in Aktion erleben.