Sicher helfen: RustDesk im Selbsthosting-Betrieb

Ich möchte RustDesk einsetzen, um im Freundes- und Bekanntenkreis bei auftretenden Computer-Problemen helfen zu können.

Die Hilfesuchenden setzen dabei Windows und MacOS ein. Support soll jeweils nur dann erfolgen, wenn die andere Person auch vor dem Gerät sitzt und den Remote-Support bestätigt.

Nachtrag (September 2026)

Der Abschnitt zur Option -k war in der ursprünglichen Fassung dieses Artikels falsch. Ich hatte empfohlen, nach dem ersten Start den Public-Key direkt an -k zu übergeben. Damit wird zwar der Zugriff auf den eigenen Key beschränkt, hbbs verliert aber den Zugriff auf seinen privaten Schlüssel und kann die Ende-zu-Ende-Verschlüsselung der Sitzungen nicht mehr verifizieren. Bis Client-Version 1.4.8 fiel das nicht auf, ab 1.4.9 erscheint beim Verbindungsaufbau die Warnung „Ende-zu-Ende-Verschlüsselung konnte nicht verifiziert werden“.

Wer nach der alten Anleitung eingerichtet hat, sollte -k in beiden Services auf _ umstellen. Die Clients müssen nicht angefasst werden, der Public-Key bleibt derselbe. Der Rest des Artikels ist entsprechend korrigiert.

iOS-Einschränkungen

Für iOS gibt es zwar eine RustDesk-App, die ist jedoch nicht in der Lage, den eigenen Bildschirm zu teilen. Das iOS-Gerät aus der Ferne zu steuern ist aufgrund von Betriebssystem-Einschränkungen überhaupt nicht möglich. Man kann sich lediglich von iOS auf andere Systeme verbinden. Eine Option für iOS-Geräte ist es, von einem anderen Apple-Gerät aus einen Facetime-Anruf zu starten und den Angerufenen dann bitten seinen Bildschirm zu teilen.

Die Public-Key Verwirrung

Beim ersten Start legt hbbs ein Schlüsselpaar an: id_ed25519 (privat) und id_ed25519.pub (öffentlich). Den öffentlichen Teil tragen die Clients in ihrer Netzwerk-Konfiguration ein.

Die Option -k steuert dabei zwei Dinge gleichzeitig, was in der offiziellen Dokumentation nicht klar wird: welchen Key ein Client vorweisen muss, und ob der Server seinen eigenen privaten Schlüssel kennt. Letzteres braucht hbbs, um den Public-Key des jeweils anderen Clients zu signieren – nur so kann ein Client beim Verbindungsaufbau prüfen, dass er tatsächlich mit dem gewünschten Gerät spricht und nicht mit jemandem, der sich dazwischen geschaltet hat.

Die möglichen Werte:

• -k _ (oder -k -): hbbs lädt das Schlüsselpaar aus der Datei, akzeptiert nur Clients mit genau diesem Public-Key und signiert die Peer-Keys. Das ist die richtige Einstellung. Bei hbbs ist - auch der Default, wenn -k ganz weggelassen wird.
• -k <public-key>: Der Zugriff wird auf diesen Key beschränkt, aber hbbs liest die Schlüsseldatei nicht mehr ein und kann nichts signieren. Die Verbindungen kommen zustande, die Ende-zu-Ende-Verifikation fehlt jedoch. Genau das hatte ich ursprünglich empfohlen.
• -k <private-key>: Funktioniert ebenfalls, hbbs leitet den Public-Key daraus ab. Der private Schlüssel steht dann allerdings in der Compose-Datei.

Bei hbbr ist es anders als bei hbbs: Ohne -k ist der Key dort leer, und dann prüft das Relay überhaupt nichts. hbbr sollte deshalb immer mit -k _ gestartet werden.

Was zu meiner ursprünglichen Fehleinschätzung geführt hat: Die Registrierung eines Clients am Server wird nicht gegen den Key geprüft. Ein Client mit falschem Key meldet sich erfolgreich an und gilt als online. Erst beim Verbindungsaufbau zu einem anderen Gerät lehnt hbbs ihn mit „Key mismatch“ ab. Wer nur bis zum Anmelden testet, bekommt den Eindruck, der Key würde nicht geprüft.

Aber: Der Public-Key ist kein Geheimnis. Wer ihn kennt, kann den Server grundsätzlich nutzen. Will man das sicher umsetzen, empfiehlt sich zusätzliche Zugriffskontrolle per Firewall, VPN oder mTLS. Oder man setzt den Pro-Server ein.

Beide Server-Komponenten (hbbr und hbbs) müssen dasselbe Schlüsselpaar sehen. Da es beim initialen Start von hbbs erzeugt wird und hbbr nur wenige hundert Millisekunden auf die Datei wartet, sollte hbbr auf hbbs warten, um eine Race-Condition zu vermeiden.

Docker-compose setup

Hier ist eine bespielhafte Docker-compose-Konfiguration:

services:
  rustdesk_hbbs:
    container_name: rustdesk_hbbs
    image: rustdesk/rustdesk-server
    restart: always
    # "_" lädt das Schlüsselpaar aus dem Volume und erzwingt diesen Key
    command: hbbs -k _
    volumes:
      - rustdesk_hbbs_data:/root
    network_mode: "host"

  rustdesk_hbbr:
    container_name: rustdesk_hbbr
    image: rustdesk/rustdesk-server
    restart: always
    # hbbr niemals ohne -k starten, sonst prüft das Relay keinen Key
    command: hbbr -k _
    depends_on: # Wait until hbbs server started
      - rustdesk_hbbs
    volumes:
      # Same volume, hbbr key must match hbbs key
      - rustdesk_hbbs_data:/root
    network_mode: "host"

volumes:
  rustdesk_hbbs_data:
    name: rustdesk_hbbs_data

Am sichersten ist es, hbbs beim ersten Mal allein zu starten, damit das Schlüsselpaar erzeugt wird, und erst danach hbbr hochzufahren. Anders als in der ersten Fassung dieses Artikels muss die Compose-Datei danach nicht mehr angepasst werden.

Ob alles stimmt, lässt sich mit zwei Blicken prüfen. Im Startlog von hbbs muss die Zeile Private key comes from id_ed25519 auftauchen; fehlt sie, kennt hbbs seinen privaten Schlüssel nicht. Und wenn man testweise auf einem Client einen falschen Key einträgt, muss der Verbindungsaufbau mit „Key mismatch“ scheitern.

Client-Konfiguration

Unter Windows sollte die Applikation über die MSI-Datei installiert werden, um Probleme mit UAC (User Account Control) zu umgehen. Der Start und die Konfiguration als Portable-App erscheint mir da zu fehleranfällig.

Auf Client-Seite muss in der Netzwerk-Konfiguration mindestens der ID-Server und der Key gesetzt werden.

Zusätzlich setze ich noch folgende Optionen:

• Allgemein – weitere Einstellungen – Automatisch aktualisieren
  • damit man sich nicht um Updates selbst kümmern muss
• Bildschirm – Entfernten Cursor anzeigen
  • ansonsten sieht der Hilfesuchende nicht den Cursor, wenn der Supporter die Kontrolle übernimmt
• Sicherheit – Passwort – “Sitzung mit Passwort bestätigen”
  • Ansonsten kann der Hilfesuchende durch das einfache Anklicken eines Popups Remote-Support freischalten – ohne, dass der Supporter das Passwort kennen muss. Ich halte da das für etwas fahrlässig.
• Sicherheit – Passwort – “Länge des Einmalpasswort”: 10
  • Persönliche Vorliebe
• Sicherheit – “Verbindung nur zulassen, wenn das Rustdesk-Fenster geöffnet ist”
  • Damit wird verhindert, dass Anfragen reinkommen, während das Programm gar nicht gestartet ist. Der “Vermittlungsdienst” muss bei Windows allerdings trotzdem dauerhaft im Hintergrund laufen und ist auch in der Taskleiste sichtbar. Das lässt sich nicht verhindern.

Mein Eindruck von RustDesk

Die Software ist prinzipiell benutzbar und eignet sich für den Remote-Support im eigenen Umfeld auch in der OSS-Variante.

Allerdings ist die Dokumentations-Situation verbesserungsbedürftig. Viele Zusammenhänge (wie die -k – Option) oder die Absicherung generell sind ungenügend beschrieben. Für das korrekte Setup muss man sich die Informationen aus Youtube-Videos, Bugtickets oder aus dem Quellcode zusammensetzen. Außerdem erfährt der OSS-Server zwar hin und wieder Commits, aber selten neue Releases.

Das wirft kein gutes Licht auf die Software, was den stabilen und sicheren Langzeit-Betrieb angeht.

Trotz dieser Einschränkungen ist RustDesk im Alltag überraschend stabil und bietet eine gute Alternative zu kommerziellen Tools – besonders dann, wenn man Wert auf Selbst-Hosting legt.