Zum Hauptinhalt springen
Open Source13 min Lesezeit

Fernwartung ins eigene Haus holen: RustDesk selbst hosten statt TeamViewer- und AnyDesk-Abos

Schritt für Schritt: Wie Sie die Bildschirmfreigabe mit dem quelloffenen RustDesk auf einen eigenen Relay-Server holen und fremde Cloud-Relays loswerden.

B
Berkan Demir
|

In fast jedem Betrieb, den ich mir ansehe, schaltet sich irgendwann jemand per Fernwartung auf einen Bildschirm. Der Dienstleister hilft beim Drucker, die Software hängt, jemand klickt aus der Ferne mit. Das läuft seit Jahren über TeamViewer oder AnyDesk, das Abo wird jedes Jahr ein Stück teurer, und kaum jemand kann sagen, über welche Server diese Verbindung eigentlich geht. Genau an dieser Stelle stellen sich Geschäftsführer und IT-Verantwortliche in KMU irgendwann zwei Fragen: Geht das günstiger, und behalte ich dabei mehr Kontrolle über meine Daten?

Die Antwort ist ja, und sie heißt RustDesk. Quelloffen, kein Bastelprojekt, aber auch kein Knopfdruck. Diese Anleitung zeigt Ihnen Schritt für Schritt, wie Sie die Fernwartung auf einen Server holen, der Ihnen gehört, Ende-zu-Ende verschlüsselt und ohne Lizenz pro Jahr. Übrig bleibt nur die Miete eines kleinen Servers.

Eine Vorbemerkung zur Erwartung. Diese Anleitung macht aus Ihnen keinen Server-Administrator, und das ist auch nicht das Ziel. Sie soll Ihnen zeigen, wie der Umstieg abläuft, woran man ihn misst und an welchen Stellen es klemmt. Wenn Sie am Ende beurteilen können, ob Ihr Dienstleister sauber gearbeitet hat, ist der Zweck erfüllt. Die eigentlichen Handgriffe macht ohnehin jemand mit der nötigen Routine, einmal, in überschaubarem Aufwand.

Hinweis

Der RustDesk-Client liegt aktuell in Version 1.4.8 vor, veröffentlicht am 21. Juni 2026. Der quelloffene Server hat den Stand 1.1.15 vom 12. Januar 2026. Wenn Sie irgendwo noch von 1.4.6 lesen: das ist bereits zwei Releases alt. Nehmen Sie immer die aktuelle stabile Version.

Warum dieser Weg

Fernwartung ist im Mittelstand Alltag. Ein Mitarbeiter kommt mit dem Drucker nicht klar, die Buchhaltungssoftware hängt, der Steuerberater braucht kurz Zugriff auf eine Datei. Jemand schaltet sich auf den Bildschirm, klickt mit, löst das Problem. Das funktioniert seit Jahren, und genau deshalb schaut kaum jemand genauer hin.

Was beim genauen Hinsehen auffällt, sehe ich in meinen Bestandsaufnahmen bei Betrieben dieser Größe immer wieder gleich: Die Fernwartung läuft über einen fremden Cloud-Dienst, das Programm steht auf jedem Rechner, und niemand kann sicher sagen, über welche Server die Verbindung eigentlich geht. Dazu kommt die Kostenseite. Die Lizenzen werden Jahr für Jahr teurer, und die Nutzungsbedingungen ändern sich, ohne dass jemand sie liest.

RustDesk dreht beide Punkte um. Das Werkzeug ist quelloffen unter der Lizenz AGPL-3.0 und in der Programmiersprache Rust geschrieben. Es verschlüsselt Sitzungen Ende-zu-Ende auf Basis der Krypto-Bibliothek NaCl. Das Entscheidende für Sie: Sie können den Server, über den die Verbindungen vermittelt werden, selbst betreiben. Damit verlassen die Daten Ihr Haus nicht mehr in fremde Hand. Das Projekt formuliert das so, dass Sie die volle Kontrolle über Ihre Daten behalten.

Was brauchen Sie dafür? Wenig. Einen kleinen Linux-Server, entweder im eigenen Netz oder bei einem deutschen oder EU-Hoster. Jemanden, der eine Firewall bedienen kann. Und einmalig etwa einen halben Tag für die Einrichtung. Den Rest macht diese Anleitung.

Es lohnt sich, kurz die Bauteile zu sortieren, weil danach alles leichter fällt. Auf der einen Seite steht der Client. Das ist das Programm, das auf den Rechnern Ihrer Mitarbeiter und Ihres Dienstleisters läuft und den Bildschirm teilt. Den gibt es fertig für Windows, Mac, Linux und Mobilgeräte. Auf der anderen Seite steht der Server, den Sie selbst betreiben. Er besteht aus zwei kleinen Diensten, die nur eine Aufgabe haben: dafür zu sorgen, dass sich zwei Clients finden und im Zweifel über Ihren Server verbunden werden. Mehr ist es nicht. Wer diese Trennung im Kopf hat, versteht jeden der folgenden Schritte sofort.

Und noch ein Wort zur Verschlüsselung, weil das die häufigste Sorge ist. Die Verschlüsselung passiert zwischen den beiden Clients, nicht auf dem Server. Selbst wenn eine Verbindung über Ihr Relay läuft, sieht das Relay nur verschlüsselte Bytes. Es kann den Inhalt der Sitzung nicht lesen. Das gilt für den öffentlichen RustDesk-Relay genauso wie für Ihren eigenen. Der Unterschied ist nicht die Sicherheit der einzelnen Sitzung, sondern wer die Vermittlung kontrolliert und wer sehen kann, wer wann mit wem verbunden war. Genau diese Kontrolle holen Sie sich mit dem eigenen Server zurück.

Tipp

Sie müssen die Einrichtung nicht selbst machen. Aber Sie sollten verstehen, was passiert, damit Sie beurteilen können, ob Ihr Dienstleister es sauber gemacht hat. Genau dafür ist diese Anleitung gedacht: als Landkarte, nicht als Prüfungsstoff.

Phase 1: Das Fundament aufbauen

In der ersten Phase entsteht der eigene Server und wird so vorbereitet, dass die beiden RustDesk-Dienste darauf laufen können. Das ist die unspektakuläre, aber wichtige Grundlage. Wer hier schludert, merkt es später an hängenden Verbindungen.

Die beiden Dienste, um die es geht, heißen hbbs und hbbr. Der hbbs ist der ID- und Rendezvous-Server: Er sorgt dafür, dass sich zwei Rechner überhaupt finden. Der hbbr ist das Relay: Er vermittelt die Verbindung, wenn ein direkter Draht zwischen den Geräten nicht zustande kommt. Beide zusammen sind das kostenlose Open-Source-Bundle, das ohne Lizenzanforderung selbst gehostet werden darf.

  1. Kleinen Server bereitstellen: Richten Sie einen schlanken Linux-Server ein, im eigenen Netz oder bei einem deutschen beziehungsweise EU-Hoster. Für KMU-Fernwartung genügt eine sehr kleine Maschine. Der Grund: Die laufenden Kosten beschränken sich auf die Miete dieses Servers. Eine Lizenzgebühr für die Open-Source-Variante gibt es nicht. Damit ist die wirtschaftliche Logik gegenüber einem Jahres-Abo schon hier entschieden.
  2. Netzzugänge öffnen: Geben Sie in der Firewall genau die Verbindungswege frei, die RustDesk für Signalisierung, das sogenannte NAT-Hole-Punching und das Relay braucht. Der Grund: Nur diese wenigen Wege werden benötigt, kein fremder Cloud-Dienst muss von außen erreichbar sein. Wichtig ist, dass auch der Weg für das Hole-Punching offen ist. Fehlt er, fallen Verbindungen unnötig oder gar nicht auf das Relay zurück. Welche Wege das genau sind, weiß Ihre IT oder ich aus der offiziellen Server-Dokumentation; es sind wenige feste Einträge.
  3. Server-Dienste starten: Bringen Sie die beiden Dienste hbbs und hbbr in Betrieb. In der Praxis laufen beide als Container nebeneinander auf demselben Server und teilen sich ein gemeinsames Datenverzeichnis. Der Grund für das gemeinsame Verzeichnis: Dort liegt unter anderem der Schlüssel, der Ihren Server eindeutig macht. Beim Start des ID-Servers wird die eigene Server-Adresse als Relay hinterlegt, damit die Dienste voneinander wissen. Die Einrichtung übernimmt Ihre IT oder ich in überschaubarem Aufwand.

Nach Phase 1 läuft der Server. Er tut allerdings noch nichts Nützliches, solange die Clients nicht wissen, dass es ihn gibt. Das ist Phase 3. Vorher kommt der Schlüssel.

Phase 2: Die Identität des Servers sichern

Jetzt kommt der Teil, der entscheidet, ob Ihre Fernwartung wirklich nur über Ihren Server läuft. Es geht um einen kryptografischen Schlüssel. Klingt technisch, ist aber im Kern eine einfache Idee.

Beim ersten Start erzeugt der ID-Server ein Schlüsselpaar. Den öffentlichen Teil davon tragen Sie später in jeden Client ein. Dieser Schlüssel bindet die Clients an genau Ihren Server. Ohne ihn könnte ein Client zwar Ihre Server-Adresse kennen, aber er hätte keine Garantie, dass er wirklich mit Ihrem Server spricht und nicht mit einem untergeschobenen. Der Schlüssel ist der Ausweis Ihres Servers.

  1. Öffentlichen Schlüssel auslesen: Lesen Sie nach dem ersten Start den öffentlichen Schlüssel aus dem Datenverzeichnis des Servers aus. Der Grund: Genau dieser Schlüssel verbindet Ihre Clients fest mit Ihrem Server. Behandeln Sie das dazugehörige private Gegenstück wie ein Passwort. Wer es verliert, verliert die Identität des Servers; wer es weitergibt, öffnet ein Tor. Deshalb gehört das gesamte Datenverzeichnis später in das Backup, dazu mehr in den Fallstricken.

Achtung

Der öffentliche Schlüssel darf verteilt werden, der private niemals. Geht das Datenverzeichnis mit dem privaten Schlüssel verloren, müssen Sie den Server neu aufsetzen und jeden Client neu konfigurieren. Sichern Sie dieses Verzeichnis von Anfang an mit.

Phase 3: Die Clients auf das eigene Haus umlenken

Bis hierhin haben Sie einen Server mit eigener Identität. Jetzt sorgen Sie dafür, dass die Rechner Ihrer Mitarbeiter ihn auch benutzen. Das ist der Schritt, an dem in der Praxis am meisten schiefgeht, weil er leicht vergessen wird. Ein Server allein ändert nichts, solange die Clients weiter die öffentlichen Relays ansteuern.

  1. Clients auf den eigenen Server zeigen lassen: Tragen Sie in jedem RustDesk-Client unter den Netzwerk-Einstellungen drei Dinge ein: die Adresse Ihres ID-Servers, die Adresse Ihres Relay-Servers und den öffentlichen Schlüssel. Der Grund: Erst mit allen drei Angaben laufen die Verbindungen über Ihren Server statt über die öffentlichen RustDesk-Relays. Fehlt der Schlüssel, ist die Bindung an Ihren Server nicht sichergestellt.
  2. Konfiguration verteilen statt abtippen: Sorgen Sie dafür, dass Mitarbeiter nichts von Hand eintippen müssen. RustDesk lässt eine vorkonfigurierte Client-Version mit hinterlegtem Server und Schlüssel zu, alternativ exportieren Sie die Einstellung als kurzen Konfigurationsstring zum Importieren. Der Grund: Was von Hand eingetragen wird, wird vergessen oder vertippt. Eine zentral verteilte Konfiguration ist firmenweit identisch und damit überprüfbar.

Nach Phase 3 sprechen alle eingerichteten Geräte mit Ihrem Server. Was jetzt noch fehlt, ist die Frage, ob das Ganze auch sicher und dauerhaft läuft. Das ist Phase 4.

Phase 4: Absichern und im Betrieb halten

Ein selbst gehosteter Server ist kein Selbstläufer. Er ist erreichbar, also muss er abgesichert sein, und er braucht Pflege. Das ist weniger Arbeit, als es klingt, aber es ist nicht null. Wer diese Phase überspringt, tauscht ein Lizenzproblem gegen ein Sicherheitsproblem. Das wäre kein guter Tausch.

  1. Zugriff absichern: Lassen Sie unbeaufsichtigten Zugriff nur mit einem starken Passwort zu, oder geben Sie jede Sitzung einzeln frei. Der Grund: Ein schwaches oder fehlendes Passwort beim unbeaufsichtigten Zugriff macht den Server angreifbar. Nutzen Sie bewusst die Bestätigungsdialoge. Die neueren Client-Versionen haben die Druckertreiber-Funktion standardmäßig abgeschaltet, was datensparsamer ist; lassen Sie es aus, wenn Sie es nicht brauchen. Halten Sie außerdem den Server aktuell, indem das Server-Image regelmäßig erneuert wird.
  2. Betrieb prüfen: Bauen Sie zum Abschluss eine Testverbindung zwischen zwei Geräten auf und kontrollieren Sie in der Sitzungsinfo des Clients, dass die Verbindung über Ihren eigenen Relay läuft. Der Grund: Erst dieser Blick beweist, dass keine Daten mehr über fremde Cloud-Relays gehen. Alles davor ist Konfiguration, dieser Schritt ist der Nachweis. Verlassen Sie sich nicht darauf, dass es läuft. Schauen Sie nach.

Tipp

Machen Sie Schritt 8 nicht einmal, sondern legen Sie ihn als kleine Routine an. Eine kurze Testverbindung pro Quartal, dazu ein Blick, ob das Datenverzeichnis im Backup ist. Das ist der Unterschied zwischen Glück und einer dokumentierten Maßnahme. Glück ist keine dokumentierte Risikomanagementmaßnahme.

Was das gegenüber den Abos bedeutet

Rechnen wir die Sache nüchtern durch, denn der Geschäftsführer entscheidet nicht über Software, sondern über Geld, Risiko und Verantwortung. TeamViewer Business kostet als Einzel-Abo für einen Benutzer, nutzbar auf bis zu drei Geräten, 433,94 Euro netto pro Jahr bei einem deutschen Händler. AnyDesk Standard für bis zu 20 Benutzer mit einer gleichzeitigen Sitzung liegt bei 387,72 Euro netto pro Jahr, die kleinere Solo-Variante bei 247,32 Euro, die größere Advanced-Stufe bei 862,92 Euro netto pro Jahr. Das sind wiederkehrende Kosten, jedes Jahr, mit der Tendenz nach oben.

Die selbst gehostete RustDesk-Variante hat keine Lizenzgebühr. Es bleibt die Miete des kleinen Servers, und die ist für eine schlanke Maschine überschaubar. Dazu kommt einmaliger Einrichtungsaufwand und etwas laufende Pflege. Das ist der ehrliche Vergleich: Sie tauschen eine planbare jährliche Lizenz gegen geringe Serverkosten plus ein wenig eigene Verantwortung.

Es gibt bei RustDesk auch eine kostenpflichtige Stufe, und die gehört ins ehrliche Bild. Der RustDesk Server Pro ist eine optionale Zusatzlizenz, kein Pflichtbestandteil. Der Basis-Plan kostet 19,90 US-Dollar pro Monat und bietet zehn Anmelde-Benutzer, hundert verwaltete Geräte und unbegrenzte gleichzeitige Verbindungen. Den Mehrwert liefern vor allem eine Weboberfläche und eine zentrale Benutzerverwaltung. Für reine Selbsthost-Fernwartung im KMU brauchen Sie das nicht. Einen offiziellen Euro-Listenpreis für Server Pro gibt es nicht; der Hersteller listet hier nur in US-Dollar. Ich rechne Ihnen daraus bewusst keinen Euro-Betrag zusammen, der wäre erfunden.

Hinweis

Manche stellen es so dar, als sei selbst hosten gratis und fertig. Das ist zu viel versprochen. Lizenzfrei heißt nicht aufwandfrei. Sie sparen die Lizenz, Sie übernehmen die Verantwortung für Server, Updates und Backup. Für viele KMU ist das ein guter Tausch, aber es ist ein Tausch, keine Gratis-Wundertüte.

Häufige Fallstricke

Diese Anleitung funktioniert, wenn Sie sie ganz durchgehen. Die typischen Probleme entstehen nicht aus Schwierigkeit, sondern aus übersprungenen Schritten. Hier sind die, die ich in der Praxis am häufigsten sehe, jeweils mit dem Gegenmittel.

  • Veraltete Version übernehmen. Irgendwo steht noch 1.4.6 aus dem März. Aktuell ist 1.4.8 vom 21. Juni 2026. Gegenmittel: Vor der Verteilung kurz die aktuelle stabile Version prüfen und genau die ausrollen.
  • Client-Konfiguration vergessen. Der Server steht, aber ein Gerät wurde nicht umgestellt. Dann laufen dessen Verbindungen weiter über die öffentlichen Relays, und Sie merken es nicht. Gegenmittel: Konfiguration zentral verteilen und mit der Testverbindung pro Gerät prüfen, nicht nur einmal.
  • Netzwege unvollständig geöffnet. Fehlt der Weg für das NAT-Hole-Punching, scheitert der direkte Verbindungsaufbau, und Verbindungen werden unnötig oder gar nicht möglich. Gegenmittel: Beim Freigeben die vollständige Liste der nötigen Wege aus der offiziellen Dokumentation nehmen, nichts auslassen.
  • Server Pro mit Open Source verwechseln. Wer denkt, er müsse die Pro-Lizenz kaufen, zahlt unnötig. Gegenmittel: Klarstellen, dass das kostenlose hbbs/hbbr-Bundle für reine Fernwartung genügt. Pro ist Komfort, kein Muss.
  • Sicherheit unterschätzen. Schwaches oder fehlendes Passwort beim unbeaufsichtigten Zugriff macht den selbst gehosteten Server angreifbar. Gegenmittel: starke Passwörter und Sitzungsbestätigung als Pflicht behandeln, nicht als Option.
  • Updates und Backup vergessen. Ohne regelmäßiges Aktualisieren drohen Sicherheitslücken, ohne Backup des Datenverzeichnisses verlieren Sie im Ernstfall die Identität des Servers samt Schlüssel. Gegenmittel: Update-Rhythmus und Backup des Datenverzeichnisses fest einplanen, am besten automatisiert.

Sie merken: Die meisten Fallstricke haben mit Disziplin zu tun, nicht mit Technik. Das ist eine gute Nachricht. Disziplin lässt sich organisieren.

Für wen sich das wirklich lohnt

Nicht jeder Betrieb sollte das tun, und es wäre unehrlich, das zu verschweigen. Wer einen einzigen Rechner ein paarmal im Jahr aus der Ferne betreuen lässt, für den ist ein eigener Server mit Pflege und Backup mehr Aufwand, als er einbringt. Da kann ein schlankes Abo oder sogar die kostenlose private Nutzung eines Standard-Werkzeugs die ruhigere Wahl sein.

Interessant wird der eigene Server, sobald drei Dinge zusammenkommen. Erstens eine gewisse Zahl an Geräten, sodass die Lizenzkosten der Abo-Welt spürbar werden. Zweitens ein echtes Datenschutz-Interesse, etwa weil über die Fernwartung regelmäßig sensible Daten sichtbar werden und Sie belegen können müssen, über welche Wege das läuft. Drittens eine IT, die ohnehin schon Server betreut, sodass ein weiterer kleiner Dienst keine neue Welt aufmacht. Treffen diese Punkte zu, kippt die Rechnung deutlich zugunsten der eigenen Lösung.

Es gibt auch den Mittelweg, und der wird oft übersehen. Sie müssen nicht alles selbst betreiben, um die Kontrolle zu behalten. Den Server kann genauso gut Ihr Dienstleister für Sie hosten, solange vertraglich klar ist, dass es Ihr Server, Ihr Schlüssel und Ihre Daten sind. Der Gewinn an Datenhoheit bleibt, der Betriebsaufwand wandert an jemanden, der ihn ohnehin täglich macht. Wichtig ist nur, dass die Identität des Servers, also der Schlüssel, eindeutig Ihnen zugeordnet bleibt und im Backup liegt, das Sie kontrollieren.

Achtung

Wenn ein Dienstleister den Server für Sie betreibt, lassen Sie sich den Zugang zum privaten Schlüssel und ein eigenes Backup des Datenverzeichnisses geben. Sonst tauschen Sie eine fremde Cloud gegen eine andere Abhängigkeit. Datenhoheit heißt, dass Sie im Zweifel ohne den Dienstleister weitermachen können.

Mein Fazit

RustDesk holt die Fernwartung zurück ins eigene Haus, ohne dass Sie dafür Lizenzen pro Jahr bezahlen. Das ist kein Hexenwerk, aber es ist auch kein Knopfdruck. Sie bekommen Kontrolle über Ihre Daten und planbar niedrige Kosten und übernehmen im Gegenzug Verantwortung für einen kleinen Server. Für KMU, die heute ein Abo zähneknirschend verlängern, ist das oft genau der richtige Tausch.

Wichtig ist die Ehrlichkeit in beide Richtungen. Selbst hosten ist nicht gratis, es ist günstig und unter Ihrer Kontrolle. Und es ist nur dann wirklich sicher, wenn Sie die letzten Schritte, das Absichern und das Prüfen, nicht weglassen. Ein Server, der über das Internet erreichbar ist, will gepflegt werden. Wer das einplant, hat eine Lösung, die Jahre trägt.

Der ehrlichste Satz zum Schluss: Die Technik ist der einfache Teil. Der schwierige Teil ist die Entscheidung, ob Sie das selbst tragen wollen oder begleitet. Genau diese Entscheidung kann Ihnen keine Anleitung abnehmen, aber ich kann sie mit Ihnen durchgehen.