Eigene Fernwartung mit RustDesk und eigenem Schlüssel

Fernwartung läuft bei den meisten Werkzeugen über die Server des Anbieters. Das ist bequem, aber jede Sitzung geht über fremde Infrastruktur. RustDesk lässt sich selbst betreiben, und dann bleibt die Verbindung bei mir. Der entscheidende Punkt dabei ist nicht der Server an sich, sondern der eigene Schlüssel. Der Reihe nach: erst die beiden Serverrollen, dann der Schlüssel, dann der Client, und am Ende, was der Selbstbetrieb im Alltag bedeutet.

Schritt 1: Die zwei Serverrollen hbbs und hbbr

Ein selbst gehosteter RustDesk besteht aus zwei Diensten, die zusammen den Weg zwischen zwei Rechnern herstellen. hbbs ist der ID- und Rendezvous-Server, über den sich die Clients finden (Ports 21115 und 21116, TCP und UDP). hbbr ist der Relay, über den der eigentliche Datenstrom läuft, wenn keine direkte Verbindung zwischen den Rechnern möglich ist (Port 21117, TCP). Was die beiden Rollen genau leisten, steht im Handbuch zum RustDesk Server OSS. Beide laufen als schlanke Container:

hbbs:
  image: rustdesk/rustdesk-server:latest
  command: "hbbs -r relay.example.de -k _"
hbbr:
  image: rustdesk/rustdesk-server:latest
  command: "hbbr -k _"

Schritt 2: Der eigene Schlüssel ist der Punkt

Das -k _ ist das Wichtige. Es weist den Server an, sein eigenes Schlüsselpaar zu verwenden und die Schlüsselpflicht zu erzwingen. Beim ersten Start legt der Server ein Paar an, id_ed25519 privat und id_ed25519.pub öffentlich. Ab dann gilt: Nur Clients, die den passenden öffentlichen Schlüssel eingetragen haben, dürfen den Server benutzen.

Das schützt gleich doppelt. Erstens kann kein Fremder meinen Relay mitbenutzen. Zweitens kann niemand einen untergeschobenen Server dazwischenschalten, denn ohne den richtigen Schlüssel kommt keine Sitzung zustande. Ohne -k wäre der Server offen, und offen ist bei einem Fernwartungs-Relay keine gute Idee.

Schritt 3: Den Client einrichten

Im RustDesk-Client trage ich unter den Netzwerk-Einstellungen drei Dinge ein: den ID-Server und den Relay-Server (beide mein eigener Host) und im Feld Key den öffentlichen Schlüssel des Servers. Der private Schlüssel bleibt ausschließlich auf dem Server, er wird nie verteilt. Wie diese Felder heißen und wo sie sitzen, ist in der Client-Konfiguration für selbst gehostete Server beschrieben.

Ehrlich: Was Selbstbetrieb bedeutet

Ein eigener Server heißt, dass ich ihn erreichbar und aktuell halte. Die Ports müssen durch die Firewall, das Image will gepflegt sein, und fällt der Host aus, fällt die Fernwartung aus. Welche Ports offen sein müssen, listet die Installationsanleitung. Für gelegentliche Einzelfälle kann ein gehostetes Werkzeug reichen. Wer aber regelmäßig auf Kundensysteme zugreift und die Sitzungen nicht über fremde Server schicken möchte, ist mit dem eigenen Relay und dem eigenen Schlüssel klar besser aufgestellt. Wer eine vollwertige Verwaltungsoberfläche braucht, kann alternativ MeshCentral betreiben, das sich hinter einen Reverse Proxy mit TLS-Offload setzen lässt.

Sie wollen Fernwartung, bei der die Verbindung nicht über fremde Server läuft? Ich richte einen eigenen Fernwartungs-Server mit eigenem Schlüssel ein, sauber abgeschottet und dokumentiert. Wie ich laufende Betreuung aufsetze, lesen Sie unter IT-Betreuung & Managed IT, das Erstgespräch ist unverbindlich.