Self host remote desktop VPS: $5 VPS Setup‑Anleitung

Dieser Leitfaden führt durch ein praktisches „self host remote desktop vps“-Setup, das Sie auf einem $5 VPS betreiben können — SSH-Schlüssel, Firewall, WireGuard, TLS. Zuerst der ehrliche Test: Hosten Sie selbst, wenn eine Anforderung Sie dazu zwingt — eine schriftliche Compliance-Auflage, ein isoliertes Netzwerk oder eine Datenresidenzregel. Wenn Sie dazu nicht gezwungen sind, ist ein verwalteter Relay günstiger, wenn man die Gesamtkosten rechnet: Bereitschaftsdienst, Einspielen von Updates, Schlüsselverwaltung, Zertifikatserneuerung, eine Region und kein Failover. Die vollständige Rechnung steht in Selbst gehosteter Remote-Desktop: der ehrliche Leitfaden 2026.

Warum ein $5 VPS ein sinnvoller Ausgangspunkt ist

Für Remote‑Desktop‑Anwendungsfälle (einzelner Nutzer, gelegentliche Sitzungen) ist ein Low‑End‑VPS oft ausreichend. Übliche $5‑Pläne (z. B. ein 1 vCPU / 1GB RAM / 25GB SSD Droplet) bei Anbietern wie DigitalOcean, Vultr oder Linode bewältigen eine gleichzeitige Sitzung, Headless‑Server‑Agents und einen leichten Relay oder VPN.

Dieser Leitfaden verwendet Ubuntu 22.04 LTS (stabil, breit unterstützt) und geht davon aus, dass der VPS über das öffentliche Internet erreichbar ist. Wenn Ihre Anforderungen GPU, Multimonitor-High-FPS-Streaming oder viele gleichzeitige Nutzer umfassen, benötigen Sie einen größeren Plan — eine dedizierte Workstation für den schweren Einsatz und den verwalteten Tenvo-Relay für die Konnektivität, damit eine einzelne $5 box in einer Region nicht zum Engpass wird.

Plan: was Sie ausführen werden und welche Ports zu erwarten sind

Die minimale Architektur hier:

• VPS (Ubuntu 22.04) mit öffentlicher IP
• SSH zur Verwaltung (nur Schlüssel)
• WireGuard als sicherer Tunnel (optional, aber empfohlen)
• Remote‑Desktop‑Server (als Beispiel verwenden wir Tenvo als Agent), ausgeführt als systemd‑Dienst
• Optional Domain + Let's Encrypt TLS und nginx Reverse‑Proxy für webbasierte Clients

Erwarteter Ressourcenverbrauch: Der Agent und das VPN liegen im Leerlauf unter 500MB RAM; die Bandbreite während einer aktiven Sitzung beträgt etwa 50 KB/s (180 MB/Stunde) bei textlastiger Arbeit, ~200 KB/s (720 MB/Stunde) für allgemeine Büroarbeit und ~1 MB/s (3,6 GB/Stunde) für Video- oder Designarbeit — ungefähr 0,4–8 Mbps, abhängig von Codec und Bildschirmaktivität. Budget: $5/month VPS + Domain (~$10/year), wenn Sie TLS möchten. Wenn Sie keine öffentlichen Ports möchten, siehe Remote Desktop ohne Portweiterleitung erklärt.

Schritt 1 — VPS bereitstellen und Zugriff absichern

Erstellen Sie einen $5 VPS mit Ubuntu 22.04. Wählen Sie bei der Erstellung die SSH‑Schlüssel‑Authentifizierung (Sie können Ihren öffentlichen Schlüssel in der Verwaltungsoberfläche des Anbieters hinzufügen). Beispielanbieter bieten ähnliche Pläne: DigitalOcean 1GB/1vCPU ($5), Vultr 1GB ($5), Linode Nanode ($5). Das genaue SKU variiert, aber Netzwerk‑ und CPU‑Spezifikationen sind vergleichbar.

Erste Härtungsbefehle (als root oder ein sudo‑Benutzer ausführen):

apt update && apt upgrade -y
adduser adminuser
usermod -aG sudo adminuser
ufw allow OpenSSH
ufw enable

Bearbeiten Sie /etc/ssh/sshd_config, um Passwort‑Authentifizierung und Root‑Login zu deaktivieren (setzen Sie PasswordAuthentication no und PermitRootLogin no). SSH neu starten: systemctl restart sshd. Das verhindert Brute‑Force‑Versuche gegen Ihren VPS.

Schritt 2 — Firewall, fail2ban und Ratenbegrenzung

Halten Sie die Firewall minimal. Wenn Sie WireGuard verwenden, erlauben Sie nur den WireGuard‑UDP‑Port in den öffentlichen Regeln; wenn Sie den Remote‑Agent direkt betreiben, benötigen Sie möglicherweise einen TCP‑Port. Beispiel‑UFW‑Regeln:

ufw allow 22/tcp          # SSH
ufw allow 51820/udp       # WireGuard (if used)
ufw allow 8443/tcp        # optional remote desktop web port
ufw enable

Installieren Sie fail2ban, um wiederholte Versuche automatisch zu sperren und Rauschen zu reduzieren: apt install -y fail2ban. Verwenden Sie das Standard‑Jail für sshd und passen Sie die Sperrzeiten Ihrem Risikoprofil an.

Schritt 3 — Sichere Netzwerkoptionen: direkte Ports, VPN oder Reverse‑Relay

Drei praktische Netzwerkmuster:

• Offener Port zum Internet: am einfachsten, aber größere Angriffsfläche. Verwenden Sie TLS und starke Authentifizierung, wenn Sie einen App-Port offenlegen.
• WireGuard-Tunnel: die sicherste, einfache Option, wenn Sie die Box selbst betreiben. Erstellen Sie ein privates Netzwerk zwischen Ihrem Client-Gerät und dem VPS; nur der WireGuard-Port ist öffentlich.
• Relay/Reverse-Connect: der Client stellt eine ausgehende Verbindung zu einem Rendezvous-Server her, sodass auf keiner Seite Inbound-Ports benötigt werden — nützlich hinter NAT und ohne VPN. Genau das macht der verwaltete Tenvo-Relay, auf einer Multi-Region-Flotte statt eines einzelnen VPS. Beachten Sie, dass wenn eine Sitzung auf das Relay zurückfällt, TLS dort terminiert, so dass wer auch immer das Relay betreibt in der Lage ist, diesen Verkehr zu sehen — Ihren oder unseren. Hintergrund zum Muster: Selbst gehosteter Remote-Desktop: Warum, wie und was schiefgeht.

WireGuard Schnellstart (Server auf dem VPS):

apt install -y wireguard iproute2
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
# create /etc/wireguard/wg0.conf and include keys + peers
systemctl enable --now wg-quick@wg0

Die WireGuard‑Konfiguration hängt von Ihrer Client‑Plattform ab; es gibt viele Tutorials und Client‑Apps für Linux, macOS, Windows, Android und iOS. Mit WireGuard wird der Remote‑Desktop‑Verkehr direkt über einen verschlüsselten Tunnel geroutet — es ist kein öffentlicher App‑Port auf dem Client erforderlich.

Schritt 4 — Installation des Remote‑Desktop‑Servers (Beispiel Tenvo)

Seien Sie präzise bezüglich dessen, was auf dem VPS läuft: nicht ein Desktop-Agent, sondern das Rendezvous-/Relay-Paar — hbbs und hbbr — das den Handshake vermittelt und die Sitzung trägt, wenn keine direkte Verbindung hergestellt werden kann. Tenvo ist AGPL-3.0 und betreibt denselben Stack, sodass Sie ihn selbst hosten können; die funktionierende Docker-Installation, Ports, Schlüssel und Client-Konfiguration sind Schritt für Schritt in Selbst gehosteter Remote-Desktop: der ehrliche Leitfaden 2026 beschrieben. Die Desktop-Clients selbst stammen von der Download-Seite. Die nachstehende systemd-Skizze ist ein generisches Muster für welchen Dienst Sie auch immer letztlich betreiben.

Beispiel: Installation eines generischen Remote‑Agents als systemd‑Dienst (ersetzen Sie das Binary und die Flags durch den Agenten Ihrer Wahl):

mkdir -p /opt/remote-relay
# scp or wget your chosen server binary to /opt/remote-relay/relay-server
chown root:root /opt/remote-relay/relay-server
chmod +x /opt/remote-relay/relay-server

cat >/etc/systemd/system/remote-relay.service <<'EOF'
[Unit]
Description=Remote desktop relay
After=network.target

[Service]
ExecStart=/opt/remote-relay/relay-server
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now remote-relay.service

Konfigurieren Sie den Agenten mit einem starken Schlüssel oder Passwort und, falls unterstützt, beschränken Sie, welche öffentlichen Client‑Schlüssel erlaubt sind. Wenn Sie WireGuard verwenden, konfigurieren Sie den Agenten so, dass er an die WireGuard‑Schnittstelle oder an die Loopback‑Adresse bindet, damit er über die öffentliche IP nicht erreichbar ist.

TLS, Domain und Reverse‑Proxy (optional)

Wenn Sie einen webbasierten Client (oder ein Admin‑UI) haben, setzen Sie nginx davor und verwenden Sie Let's Encrypt für TLS. Praktische certbot‑Befehle auf Ubuntu 22.04:

apt install -y nginx certbot python3-certbot-nginx
# create nginx site for example.com and proxy_pass to localhost:8443
certbot --nginx -d example.com

Lassen Sie die automatische Erneuerung des TLS‑Zertifikats aktiv (certbot richtet dies ein). Wenn Sie eine Domain verwenden, zeigen Sie einen A‑Record auf die IP Ihres VPS und verwenden Sie die Domain in Ihren Client‑Konfigurationen. TLS schützt Web‑UIs und browserbasierte Clients; es ersetzt keine starke Agenten‑Authentifizierung.

Tests und Verifikation

Grundlegende Prüfungen:

• SSH: Versuchen Sie eine Passwortanmeldung — sie sollte fehlschlagen.
• WireGuard: Starten Sie den Client und pingen Sie die WireGuard-IP des VPS an.
• Agent: Verbinden Sie sich von Ihrem Client mit dem Agenten über die WireGuard-Schnittstelle oder den TLS-Endpunkt; überprüfen Sie Latenz sowie Audio-/Videoqualität.
• Protokolle: Prüfen Sie journalctl -u remote-relay -f (wie auch immer Sie die Unit oben genannt haben) und /var/log/nginx/error.log während der Verbindung.

Messen Sie Bandbreite und CPU während einer Sitzung. Wenn Sie hohe CPU‑Last auf dem VPS beobachten, reduzieren Sie die Encoding‑Qualität, senken Sie die Bildrate oder verschieben Sie den Sitzungsbroker auf eine leistungsfähigere Instanz.

Wartung: Updates, Backups und Monitoring

Planen Sie OS‑Updates und Neustarts für Zeiten mit geringer Auslastung. Verwenden Sie unattended‑upgrades für Sicherheits‑Patches, testen Sie größere Upgrades jedoch manuell. Erstellen Sie vor risikoreichen Änderungen einen Snapshot der VPS‑Festplatte über den Anbieter und speichern Sie eine Kopie extern zur Wiederherstellung.

Monitoring‑Tipps: Aktivieren Sie das Basis‑Monitoring in der Verwaltungskonsole Ihres Anbieters (die meisten zeigen CPU, Bandbreite und Festplatte) und erwägen Sie ein einfaches Alerting (E‑Mail bei vollem Datenträger oder hoher CPU). Rotieren Sie Ihre SSH‑Schlüssel jährlich und widerrufen Sie verlorene Schlüssel sofort.

Wann dies nicht die richtige Wahl ist

Self-Hosting auf einem $5 VPS passt gut als Laborbox oder wenn eine Anforderung Ihnen keine Wahl lässt. Für den persönlichen Gebrauch und kleine Teams ist es normalerweise die teurere Option, sobald Ihre eigene Zeit als Kostenfaktor einbezogen wird. Es ist außerdem nicht die richtige Wahl, wenn Sie benötigen:

• Niedrige Latenz für Clients in verschiedenen Regionen oder irgendeine Form von Failover — ein $5 VPS ist ein Standort und eine Maschine. Der verwaltete Tenvo-Relay betreibt denselben hbbs/hbbr-Stack auf einer Multi-Region-Flotte: Kostenlos $0, Lite $2.99/Monat, Pro $7.99/Monat, gegenüber $5 für den VPS plus Ihre eigene Bereitschaftsrotation, Patching und Zertifikatserneuerung. Für ein Team siehe die Business-Pläne.
• GPU-beschleunigtes Streaming oder viele gleichzeitige Nutzer — dafür werden größere Instanzen oder dedizierte Hardware benötigt.

Für sicherheitsorientierte Leser lesen Sie auch unseren ausführlicheren Beitrag zur Sicherung des Remote-Zugriffs: Remote-Desktop-Sicherheit: Was Sie wissen müssen. Für die vollständige Gegenüberstellung Hosted vs. Self-Hosted — Bandbreite, Bereitschaftsdienst, Schlüsselverwaltung, Zertifikatserneuerung — siehe Selbst gehosteter Remote-Desktop: der ehrliche Leitfaden 2026.

Fazit und nächste Schritte

Technisch ist das unkompliziert: Verwenden Sie SSH-Schlüssel, sichern Sie die Box mit einer Firewall, bevorzugen Sie WireGuard, damit weniger Anwendungsports exponiert sind, und betreiben Sie den Dienst unter systemd. Was die obigen Schritte nicht zeigen, sind die laufenden Kosten — Sie sind die Bereitschaftsrotation, der Patchplan, die Schlüsselverwaltung und die Zertifikatserneuerung, auf einer Maschine in einer Region ohne Failover. Es lohnt sich, wenn eine Compliance-Auflage, ein isoliertes Netzwerk oder eine Residency-Regel dies verlangt. Sonst nicht.

Also: Wenn eine Anforderung Sie zum Self-Hosting verpflichtet, starten Sie den $5 VPS, folgen Sie den oben genannten Schritten und nutzen Sie Selbst gehosteter Remote-Desktop: der ehrliche Leitfaden 2026 für die funktionierende hbbs/hbbr-Installation und die vollständige Aufschlüsselung der laufenden Kosten. Wenn Sie zu nichts verpflichtet sind, lassen Sie die Box aus: laden Sie den Client herunter und starten Sie mit dem verwalteten Relay — Kostenlos $0, Lite $2.99/Monat, Pro $7.99/Monat unter Preise, oder Business-Pläne für ein Team.