Es gibt zahlreiche Programme für die Remote-Unterstützung. Im deutschsprachigen Raum zählen TeamViewer, AnyDesk, X2Go und Zoho Assist zu den bekanntesten. Bei all diesen Lösungen ist es wichtig, dem Anbieter zu vertrauen, da die Vermittlungssoftware nicht selbst gehostet werden kann. Ein Sicherheitsvorfall bei TeamViewer ist vielen noch in Erinnerung.
RustDesk ist eine voll ausgestattete Open-Source-Alternative für die Fernsteuerung mit Self-Hosting und Sicherheit bei minimaler Konfiguration. Sie haben die volle Kontrolle über Ihre Daten, ohne Sicherheitsbedenken.
Die ersten Schritte.
Für den ersten Testlauf genügt es, wenn sowohl der Unterstützer als auch der Hilfesuchende den RustDesk-Client herunterladen. Dieser steht für viele Plattformen zur Verfügung. Für den Unterstützer gibt es auch eine Web-Version.

https://github.com/rustdesk/rustdesk/releases
Beide Seiten starten den Client.

Zunächst gibt der Unterstützer die ID ein, anschließend das Einmalpasswort, das ihm vom zu Unterstützenden auf beliebigem Weg übermittelt wurde. Danach ist die Verbindung hergestellt.

Soweit, so einfach. Es bleibt jedoch das Problem, dass die Vermittlung von einem externen Server durchgeführt wird, der nicht unter eigener Kontrolle steht.
Um den Zugriff auf beliebige Rechner besser abzusichern, kann ein eigener Vermittlungsserver betrieben werden.
RustDesk-Server mit docker compose
Uns steht bereits ein interner Docker-Host zur Verfügung, auf dem beispielsweise UptimeKuma und andere Docker-basierte Dienste laufen. Einen zusätzlichen Docker-Container auf diesem Host laufen zu lassen, ist wenig Aufwand.
wget rustdesk.com/oss.yml -O compose.yml
sudo docker compose up -d
Diese zwei Befehle starten zwei Container – hbbs und hbbr
hbbs steht für den Signalingserver und
hbbr steht für den Relayserver und helfen quasi beide Seiten sich zu finden.
Sobald beide Container laufen, wird ein Verzeichnis namens „data” erstellt. Dort befindet sich auch der öffentliche Schlüssel, den wir benötigen. Mit dem Befehl „cat” geben wir den öffentlichen Schlüssel aus und kopieren ihn.
cat ./data/id_ed25519.pub
liefert z.B. ZdI1NTE5AAAAIMSslDKiThqQGBi3y93QEbIGgR+1P14=
Nun öffnen wir den RustDesk-Client des Zielrechners, also des Computers, mit dem wir eine Verbindung herstellen möchten. In den Einstellungen werden folgende Daten eingetragen: In unserem Fall die IP-Adresse des Docker-Servers, auf dem der Signaling- und der Relay-Server laufen, sowie natürlich der öffentliche Schlüssel.

Die gleichen Einstellungen sind dann auch vom „Unterstützer“-Client erforderlich.
Wenn der Unterstützer-Client z. B. von zu Hause oder über mobile Daten eine Verbindung aufbauen möchte, ist klar, dass das noch nicht funktionieren kann. Der Docker-Server bzw. die im Bild sichtbare IP-Adresse 192.168.1.10 ist eine interne Adresse, die nicht geroutet wird und nach außen nicht sichtbar ist. Das Problem lässt sich lösen, indem die Firewall entsprechend angepasst wird. Das ist jedoch nicht unbedingt notwendig. Es funktioniert auch, wenn man einen Socks-Proxy verwendet, der einen Tunnel ins interne Netz gräbt. Dazu reicht ein SSH-Client aus.
Mit „ssh -D 5000 USER@PUBLIC-IP“ kann man schnell einen Socks-Proxy bzw. Tunnel on-the-fly ins Schulnetz aufbauen.
Dieser muss dann noch am RustDesk-Client des Unterstützers eingetragen werden.

Das hat für uns mehrere Vorteile
a.) Der RustDesk-Server ist nur im internen Netz erreichbar und nicht via Internet und ist somit von Angriffen aus dem Internet entsprechend geschützt.
b.) Für eine RustDesk-Session aus dem Internet ist immer eine SSH-Verbindung notwendig.
c.) Der SSH-Zugang funktioniert nur über ein paar fix definierte IP-Adressen und Benutzer, wodurch sich auch nur wenige Angriffsmöglichkeiten ergeben.
Referenzen:
https://rustdesk.com/docs/de
https://github.com/rustdesk/rustdesk
https://github.com/rustdesk/rustdesk-server
https://www.andysblog.de/fernwartung-mit-rustdesk-zum-selber-hosten
Image by WOKANDAPIX from Pixabay
0 Kommentare