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.

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

Eine Besonderheit gibt es bei dem Setup des OSS-Servers zu beachten: Wenn man keine Vorkehrungen trifft, erlaubt der Server auch Verbindungen Dritter. Will man das verhindern, muss man der Option -k den Public-Key mitgeben, der beim ersten Starten angelegt wird.

Leider ist die offizielle Dokumentation an dieser Stelle nicht besonders gut. Wird -k gar nicht angegeben oder mit -k - konfiguriert, erlaubt der Server nur Verbindungen mit Clients, die einen Public-Key konfiguriert haben. Allerdings kann dieser Public-Key beliebig sein!

Deshalb ist es wichtig, dass nach dem initialen Start (bei der ein Random-Key erzeugt wird) die Konfiguration so zu verändern, dass nur genau dieser Key akzeptiert wird (-k <pub-key>).

Mit der Option -k <pub-key> akzeptiert der Server nur Clients die exakt diesen Public Key eingetragen haben. Clients ohne oder mit anderem Key können keine Sitzungen aufbauen – sie sehen den Server zwar, können sich auch per TCP verbinden, können ihn aber nicht nutzen.

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 dabei denselben Key verwenden. Da er beim initialen Starten von beiden in eine Datei id_ed25519.pub geschrieben wird, 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
    # Change from "hbbs -k -" to "hbbs -k <our-pub-key>" after initial start
    command: hbbs -k -
    volumes:
      - rustdesk_hbbs_data:/root
    network_mode: "host"
  
  rustdesk_hbbr:
    container_name: rustdesk_hbbr
    image: rustdesk/rustdesk-server
    restart: always
    # Change from "hbbr -k -" to "hbbr -k <our-pub-key>" after initial start
    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

Wie oben angemerkt, sollte nach dem initialen Starten der Aufruf von hbbr und hbbs verändert werden und der tatsächliche Public-Key für das Argument -k aus der Datei
id_ed25519.pub eingetragen werden.

Am sichersten ist es, hbbs beim ersten Mal allein zu starten, damit der Key erzeugt wird, und erst danach hbbr hochzufahren.

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.