Linux‑Remote‑Desktop‑Server: X11VNC‑ und RustDesk‑Daemon‑Einrichtung

Sie möchten Personen (oder sich selbst) ermöglichen, sich zuverlässig, sicher und ohne Umweg über teure proprietäre Dienste mit einem Linux‑Desktop zu verbinden — und die Handbücher, die Sie gefunden haben, sind entweder zu ungenau oder für GUI‑Benutzer geschrieben. Dieser Leitfaden zeigt zwei praktikable serverseitige Ansätze für einen Linux‑Remote‑Desktop‑Server: eine erprobte X11VNC‑Konfiguration zur direkten Exposition einer X‑Session und einen selbstgehosteten RustDesk‑Daemon (hbbs/hbbr) für moderne NAT‑Traversal und Relay — mit echten Befehlen, systemd‑Units, Docker‑Beispielen und konkreten Härtungsschritten.

Warum einen Linux-Remote-Desktop-Server betreiben? Kurze Entscheidungsübersicht

Bevor Sie in die Befehle eintauchen: Wählen Sie ein Modell, das Ihren Anforderungen entspricht.

• Wenn Sie direkten Zugriff auf die physische X‑Session einer Maschine benötigen (unterstützt den angemeldeten Benutzer, lokalen Sitzungszustand, mehrere Monitore), ist X11VNC das einfachste serverseitige Werkzeug.
• Wenn Sie ein Client/Server‑Modell wünschen, das NAT‑Traversal, ID‑Server, Relays und einfachere plattformübergreifende Clients unterstützt — und Sie diese Serverkomponenten selbst hosten möchten — betreiben Sie die RustDesk‑Daemon(s) hbbs/hbbr.
• Wenn Sie lediglich einen schnellen Einzelmaschinen‑Tunnel für einmalige Unterstützung benötigen, ist ein SSH‑Tunnel oder die Nutzung eines gehosteten Dienstes häufig schneller. Siehe auch unseren Leitfaden zu selbstgehostetem Remote‑Desktop für Strategie und Abwägungen.

Hinweis: Kommerzielle Produkte wie TeamViewer und AnyDesk sind in puncto reiner Bequemlichkeit (automatische NAT‑Traversal und optimierte Codecs sofort einsatzbereit) oft überlegen. Sie sind eine sinnvolle Wahl, wenn Sie Plug‑and‑Play‑Zuverlässigkeit und kommerziellen Support benötigen; siehe unseren Vergleich zu Funktionsunterschieden in rustdesk-vs-anydesk.

1) X11VNC: ein minimaler Linux-Remote-Desktop-Server, der die physische X‑Session exponiert

X11VNC verbindet sich mit einem bestehenden X‑Server und stellt den aktuellen Desktop bereit. Es ist kein separater virtueller Desktop — es spiegelt die lokal angemeldete GUI. Das macht es hervorragend für Fernsupport und Administration, wenn Sie mit derselben Sitzung interagieren möchten, die ein lokaler Benutzer sieht.

Voraussetzungen und empfohlene Versionen

• Funktioniert auf X11‑basierten Desktops. Für Wayland verwenden Sie compositorspezifische Remote‑APIs oder einen anderen Ansatz.
• Installieren Sie x11vnc >= 0.9.16 (0.9.16+ unterstützt moderne Funktionen und Stabilitätsverbesserungen).
• Stellen Sie sicher, dass ein Display‑Manager (gdm/lightdm/sddm) oder eine X‑Session auf :0 läuft.

Installation auf Debian/Ubuntu (Beispiel):

sudo apt update
sudo apt install -y x11vnc xauth

Erstellen Sie eine Passwortdatei (sicher aufbewahren):

sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo chown root:root /etc/x11vnc.pass
sudo chmod 600 /etc/x11vnc.pass

Einfache systemd‑Unit zum automatischen Start auf Display :0 (als /etc/systemd/system/x11vnc.service ablegen):

[Unit]
Description=x11vnc - VNC server for :0
After=display-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -ncache 10
User=root
Restart=on-failure

[Install]
WantedBy=graphical.target

Aktivieren und starten:

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo systemctl status x11vnc.service

Sicherheitsanmerkungen für X11VNC

• Setzen Sie TCP/5900 nicht ohne zusätzliche Schutzmaßnahmen direkt dem Internet aus. Die VNC‑Authentifizierung ist für LAN‑Einsatz akzeptabel, sollte aber in öffentlichen Netzen als schwach angesehen werden.
• Bevorzugen Sie für Fernzugriff einen SSH‑Tunnel: ssh -L 5900:localhost:5900 user@your-server und verbinden Sie dann einen VNC‑Client mit localhost:5900.
• Wenn Sie direkte TLS‑Absicherung benötigen, verwenden Sie stunnel oder ein VPN. Alternativ VNC hinter eine ordentliche Firewall stellen und VPN‑Zugang erzwingen.

Performance‑Tipps

• Verwenden Sie -ncache 10, um Bandbreitenspikes zu reduzieren, wenn sich der Desktopinhalt schnell ändert.
• Wenn Sie auf 1–2 Mbps‑Verbindungen hohe CPU‑Last sehen, reduzieren Sie die Farbtiefe oder verwenden Sie Kompressionsoptionen (x11vnc unterstützt -compresslevel und -quality). Experimentieren Sie — niedrigere Qualität führt oft zu besserer gefühlter Reaktionsfähigkeit.

2) RustDesk‑Daemon: selbstgehosteter Relay‑ und ID‑Server für modernen Fernzugriff

RustDesk stellt einen Client bereit, der einen zentralen ID‑Server (hbbs) und einen Relay (hbbr) verwenden kann, um Peers auch hinter NAT zu verbinden. Eigene hbbs/hbbr zu betreiben gibt Ihnen volle Kontrolle über IDs und Relays — wichtig, wenn Sie Drittanbieter‑Server vermeiden möchten. Dies ist die serverseitige Konfiguration, die die meisten meinen, wenn sie im selbstgehosteten Modell nach einem Linux‑Remote‑Desktop‑Server fragen.

Warum hbbs/hbbr statt einer einzelnen Binärdatei betreiben? Hbbs ist der ID‑Server (Authentifizierung, Zuweisung), hbbr ist der Relay‑Server (TCP/UDP‑Relay für Medien, wenn direkte P2P‑Verbindungen fehlschlagen). Beide sind schlank und werden häufig in Docker betrieben.

Empfohlene Versionen: Verwenden Sie die RustDesk‑Serverkomponenten 1.1.9+ (oder das jeweils aktuelle stabile Tag zum Zeitpunkt der Bereitstellung). Prüfen Sie die Release‑Notes des RustDesk‑Projekts vor produktiven Rollouts.

Beispiel Docker Compose für hbbs + hbbr (minimal)

version: '3.3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"  # hbbs TCP (ID server)
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbs:/data

  hbbr:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbr
    restart: unless-stopped
    ports:
      - "21116:21116/tcp"  # hbbr TCP (relay)
      - "21116:21116/udp"  # hbbr UDP for hole punching/relay
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbr:/data

Hinweise zu Ports und NAT

• Standardmäßig werden bei RustDesk üblicherweise die Ports 21115 (hbbs ID‑Server) und 21116 (hbbr Relay) gemappt. UDP ist für NAT‑Traversal nützlich; öffnen Sie nach Möglichkeit sowohl TCP als auch UDP.
• Halten Sie den Server auf einer öffentlichen IP oder einem Host mit statischer IP/DNS. Verwenden Sie einen A/AAAA‑Eintrag für den Hostnamen, den Sie in den Clients konfigurieren.

Client‑Seite konfigurieren

Weisen Sie den RustDesk‑Client auf Ihren hbbs‑Hostnamen und aktivieren Sie Relay bei Bedarf. Sie können die Relay‑Nutzung zur Wahrung der Privatsphäre erzwingen oder Peer‑to‑Peer erlauben, wenn beide Clients NAT durchstoßen können. Die Client‑Konfigurationsoberfläche akzeptiert den Hostnamen und Port Ihres Servers (z. B. server.example.com:21115).

Absicherung einer selbstgehosteten RustDesk‑Daemon‑Bereitstellung

Der Standardverkehr von RustDesk ist zwischen Peers verschlüsselt, aber die Serverkomponenten authentifizieren und koordinieren. Ziehen Sie diese Härtungsmaßnahmen in Betracht:

• Betreiben Sie hbbs/hbbr hinter einer Firewall und öffnen Sie nur notwendige Ports (21115 TCP, 21116 TCP/UDP). Verwenden Sie UFW oder firewall‑cmd; Beispiel: sudo ufw allow 21115/tcp; sudo ufw allow 21116/tcp; sudo ufw allow 21116/udp.
• Verwenden Sie TLS/HTTPS für jede webseitige Admin‑UI, die Sie hinzufügen. Wenn Sie TLS an einem Reverse‑Proxy (nginx/caddy) terminieren, halten Sie das Backend isoliert.
• Überwachen Sie Logs und Ressourcennutzung. RustDesk‑Komponenten sind leichtgewichtig, aber Sie sollten Verbindungszahlen und Relay‑Bandbreite beobachten.
• Erwägen Sie Rate‑Limiting und fail2ban auf dem Host, wenn Sie Brute‑Force‑Versuche gegen den hbbs‑Port feststellen.

Wann RustDesk vs. X11VNC wählen

• Wählen Sie RustDesk, wenn Sie plattformübergreifende Client‑Unterstützung (Windows/Mac/Linux/Android/iOS), NAT‑Traversal und einen zentralen selbstgehosteten ID/Relay‑Server für viele Endpunkte benötigen. Es ist eine moderne Lösung für verteilte Flotten.
• Wählen Sie X11VNC, wenn Sie einzelne Desktop‑Maschinen betreuen und mit der lokalen X‑Session interagieren müssen (z. B. zur Fehlerbehebung beim angemeldeten Benutzer oder bei grafischen Boot‑Problemen).

Praktische Hinweise für den Produktivbetrieb und Performance‑Tuning

Bandbreite und CPU: Rechnen Sie damit, dass direkte Remote‑Desktop‑Sitzungen bei typischen Office‑Aufgaben mit komprimierten Codecs zwischen 1–5 Mbps verbrauchen; Bildschirmübertragung von Videos oder Spielen führt zu deutlich höheren Spitzen. Wenn Sie Ihr eigenes Relay (hbbr) betreiben, planen Sie Relay‑Bandbreite ein: 100 gleichzeitige Sitzungen à 2 Mbps = ~200 Mbps dauerhafte Kapazität.

Monitoring und Autoscaling: Für größere Organisationen betreiben Sie hbbs hinter einem kleinen HA‑Proxy oder Load‑Balancer und setzen mehrere hbbr‑Relays verteilt über Regionen ein. Verwenden Sie Standard‑Container‑Orchestrierung (Docker Swarm oder Kubernetes), wenn Sie Auto‑Scaling benötigen; andernfalls genügt für kleine Teams eine einzelne leistungsstarke Relay‑VM.

Logging und Fehlersuche

• x11vnc‑Logs erscheinen im systemd‑Journal: sudo journalctl -u x11vnc.service
• RustDesk‑Container: docker logs rustdesk_hbbs und docker logs rustdesk_hbbr für Startfehler. Prüfen Sie Port‑Erreichbarkeit mit ss oder netstat und testen Sie UDP/TCP von einem entfernten Client.
• Wenn direkte Verbindungen fehlschlagen, prüfen Sie, ob UDP nicht durch Zwischen‑NATs oder Firewalls blockiert wird; viele Carrier blockieren ungewöhnliche UDP‑Bereiche.

Sicherheitsvergleich und ehrliche Einschätzung der Anbieter

Wenn Sicherheit und Datenschutz Ihre höchsten Prioritäten sind, gibt Ihnen das Selbsthosting von hbbs/hbbr Kontrolle über Metadaten und Relay‑Endpunkte. Proprietäre Anbieter wie TeamViewer oder AnyDesk bieten allerdings oft bessere sofort einsatzfähige NAT‑Traversal, proprietäre Codecs mit niedrigeren Bitraten für schlechte Verbindungen und Enterprise‑Support/SLAs. Sie sind vorzuziehen, wenn Sie garantierten 24/7‑kommerziellen Support und einfachere Einarbeitung für nicht‑technische Nutzer benötigen — aber diese Bequemlichkeit hat ihren Preis. Siehe anydesk-pricing-explained für Preisunterschiede und Abwägungen.

Praktische Checkliste vor dem Live‑Gang

1. Entscheiden Sie, welches Modell zu Ihnen passt (X11VNC für physische Sessions vs. RustDesk für ID/Relay‑basierten Fernzugriff).
2. Härten Sie den Server: Firewall, nur SSH‑Keys, fail2ban‑Rate‑Limiting und TLS, wo anwendbar.
3. Testen Sie von außerhalb Ihres Netzwerks: Überprüfen Sie Relay‑Verhalten, Latenz und Failover.
4. Richten Sie Monitoring ein (Logs, Bandbreite, Prozess‑Restarts) und eine Alarmpolitik für Ausfälle.

Weiterführende Lektüre und interne Ressourcen

Wenn Sie breitere selbstgehostete Optionen und Abwägungen evaluieren, lesen Sie unseren Leitfaden unter /self-hosted-remote-desktop. Für einen fokussierten Funktionsvergleich zwischen RustDesk und kommerziellen Optionen siehe /rustdesk-vs-anydesk.

Abschließende praktische Hinweise

Beide Ansätze sind wartbar, lösen aber leicht unterschiedliche Probleme. X11VNC ist einfach und vorhersehbar für einzelne Desktops; RustDesk‑Daemon(s) skalieren besser für Flotten und handhaben NAT‑Traversal elegant, wenn sie richtig konfiguriert sind. In allen Fällen: Setzen Sie unverschlüsseltes VNC niemals direkt dem Internet aus — verwenden Sie immer SSH‑Tunnel, VPNs oder ein ordentlich gehärtetes Relay.

Bereit, es selbst auszuprobieren? Laden Sie Tenvo (godeskflow)‑Clients herunter oder prüfen Sie unsere Server‑Dokumentation unter /download — und wenn Sie Preis‑ oder Enterprise‑Optionen benötigen, sehen Sie sich /pricing an. Stellen Sie eine Testinstanz bereit, prüfen Sie Ihre Firewall‑Regeln und validieren Sie das Verhalten der Clients, bevor Sie für Nutzer ausrollen.