SSH über Tor-Onion-Service ohne offene Ports

Was sich bei SSH über einen Tor-Onion-Service ändert

SSH über einen Tor-Onion-Service ermöglicht die Verwaltung eines VPS, der an keinem Port eingehende Verbindungen akzeptiert. Der Server baut selbst eine Verbindung zum Tor-Netzwerk auf und hält sie offen. Ihre SSH-Sitzung läuft über diese Verbindung zurück, sodass am öffentlichen IP-Adressbereich nichts auf Verbindungen lauschen muss.

Die Auswirkung auf das Log ist sofort sichtbar. Ein System mit einem öffentlichen SSH-Port verzeichnet durch Scanner täglich Tausende fehlgeschlagene Passwortversuche. Wenn Sie sshd hinter einem Onion-Service betreiben und eingehenden Datenverkehr in der Firewall verwerfen, protokolliert /var/log/auth.log anschließend nur noch die von Ihnen gestarteten Sitzungen.

Der Nachteil ist, dass tor bei jeder Administrationssitzung im Datenpfad liegt. Es handelt sich um einen Daemon im Userspace, der nach jedem Reboot gestartet werden und den Verbindungsaufbau zum Tor-Netzwerk abschließen muss, bevor Sie sich anmelden können. Planen Sie das, bevor Sie den Port schließen. Andernfalls können Sie den Zugriff auf ein System verlieren, das Sie nicht physisch erreichen können.

Schaffen Sie sich einen Rückweg, bevor Sie etwas ändern

Beginnen Sie erst, wenn Sie über einen Wiederherstellungsweg verfügen, der kein SSH verwendet.

Öffnen Sie jetzt die Konsole Ihres Providers, also die VNC- oder serielle Konsole im Control Panel, und melden Sie sich darüber an. Wenn das root-Passwort unbekannt ist, setzen Sie das root-Passwort zunächst über das Panel zurück und bestätigen Sie, dass die Anmeldung funktioniert. Eine Konsole, die Sie noch nie getestet haben, ist kein Wiederherstellungsweg.

Die folgende Reihenfolge ist wichtig. Jeder Schritt wird erfolgreich geprüft, bevor der nächste ausgeführt wird. Port 22 bleibt geöffnet, bis die Onion-Route funktioniert.

1. Installieren Sie tor und bestätigen Sie, dass der Bootstrap-Vorgang erfolgreich ist.
2. Definieren Sie den Onion Service und lesen Sie die Adresse ab.
3. Verbinden Sie sich über die Onion-Route, während Port 22 noch geöffnet ist.
4. Fügen Sie die Client-Autorisierung hinzu und verbinden Sie sich erneut.
5. Binden Sie sshd an loopback und schließen Sie Port 22.
6. Starten Sie den Server neu und verbinden Sie sich anschließend erneut über die Onion-Route.

Lassen Sie Ihre aktuelle SSH-Sitzung während des gesamten Vorgangs geöffnet. Eine bestehende Sitzung bleibt auch bei einer Firewall-Änderung bestehen, die eine neue Sitzung blockieren würde. Sie ist daher Ihre erste Rettungsmöglichkeit.

Tor auf dem Server installieren

Ubuntu stellt tor im eigenen Repository bereit, aber diese Version ist oft veraltet. Das Repository des Tor Project enthält die Version, die in der Dokumentation des Projekts beschrieben wird. Fügen Sie es mit den Befehlen aus dem apt-Repository-Leitfaden hinzu.

sudo apt update
sudo apt install -y apt-transport-https wget gpg
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Geben Sie /etc/apt/sources.list.d/tor.sources ein. Suites verwendet den Release-Codenamen, den lsb_release -cs ausgibt (noble unter Ubuntu 24.04).

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
sudo journalctl -u tor@default -n 20 --no-pager

Das Log sollte mit Bootstrapped 100% (done) enden. Wenn der Dienst an dieser Stelle hängen bleibt, kann tor das Netzwerk nicht erreichen. Fast immer ist eine ausgehende Firewall-Regel oder eine stark falsch eingestellte Uhr die Ursache.

Der Name der Unit ist eine Falle. systemctl status tor meldet Active: active (exited), obwohl alles korrekt funktioniert, weil Debian und Ubuntu tor als Multi-Instance-Master-Unit paketieren, deren einzige Aufgabe darin besteht, die eigentliche Instanz zu starten. Der Daemon läuft selbst als tor@default.service. Verwenden Sie diesen Namen für status und für journalctl. Start, Stopp und Reload von tor erreichen die Instanz trotzdem, daher funktioniert sudo systemctl reload tor wie erwartet.

Onion-Service für Port 22 definieren

Fügen Sie /etc/tor/torrc zwei Zeilen hinzu.

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

Die zweite Zeile weist Tor an, den virtuellen Port 22 unter der Onion-Adresse anzunehmen und eine Verbindung zu 127.0.0.1:22 auf dem Server herzustellen. Tor erreicht sshd über das Loopback-Interface. Genau deshalb kann sshd später aufhören, an der öffentlichen Adresse zu lauschen. Zeigen Sie in dieser zweiten Zeile stattdessen auf einen Webserver auf 127.0.0.1:80. Mit denselben beiden Direktiven veröffentlichen Sie eine Website unter einer Onion-Adresse. Das ist ein sinnvoller zweiter Dienst, den Sie nach der Installation von Tor betreiben können.

sudo systemctl reload tor
sudo cat /var/lib/tor/ssh/hostname

Die Ausgabe enthält 56 Base32-Zeichen, gefolgt von .onion. Diese Zeichen sind der codierte öffentliche Schlüssel des Dienstes. Es gibt dabei weder eine Zertifizierungsstelle noch eine Namensregistrierung.

Lassen Sie Tor /var/lib/tor/ssh/ selbst erstellen. Wenn Sie das Verzeichnis manuell mit dem falschen Eigentümer oder mit einem weniger restriktiven Modus als 0700 anlegen, verweigert Tor die Verwendung. Das Journal meldet dann, dass die Berechtigungen des Verzeichnisses zu großzügig sind. Die Dateien darin enthalten die Identität des Dienstes: hs_ed25519_secret_key ist die Adresse. Sichern Sie dieses Verzeichnis mit dem Modus 600 und bewahren Sie die Kopie außerhalb des Servers auf. Geht es verloren, benötigen Sie eine neue Adresse und müssen die Konfiguration auf jedem Client anpassen.

Verbindung von Ihrer Workstation herstellen

Auf Ihrer Workstation muss ein Tor-Client installiert sein. Er benötigt keinerlei Konfiguration. Unter Debian oder Ubuntu ist das sudo apt install -y tor netcat-openbsd. Tor lauscht anschließend unter 127.0.0.1:9050 als SOCKS5-Proxy. SOCKS ist ein generisches Proxy-Protokoll. Version 5 kann statt einer IP-Adresse einen Hostnamen übertragen. Genau das ist hier relevant.

OpenSSH verfügt über keinen eigenen SOCKS-Client. Daher übernimmt ein Hilfsprogramm die Verbindung. Fügen Sie dies zu ~/.ssh/config hinzu.

Host myvps
  HostName xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion
  User admin
  ProxyCommand /usr/bin/nc -X 5 -x 127.0.0.1:9050 %h %p
  ServerAliveInterval 30

-X 5 wählt SOCKS5 aus. -x 127.0.0.1:9050 verweist auf den lokalen Tor-Dienst. %h übergibt den Onion-Namen als Namen an Tor. Tor löst ihn dadurch innerhalb des Netzwerks auf. Dafür muss es sich um OpenBSD netcat handeln. GNU netcat unterstützt die Option -X nicht und beendet sich mit nc: invalid option -- 'X'.

ssh myvps

Die erste Verbindung ist langsam, weil Tor zunächst einen Circuit aufbaut. Akzeptieren Sie den Fingerabdruck des Hostschlüssels wie bei jeder anderen Verbindung. Danach gilt die übliche SSH-Schlüsselverwaltung unverändert. Der Transportweg hat sich geändert. Die Authentifizierung nicht.

Für eine einmalige Verbindung können Sie auf den Konfigurationseintrag verzichten: torsocks ssh admin@xxxxx.onion erledigt dieselbe Aufgabe.

Clientautorisierung für v3 hinzufügen

Derzeit kann jeder, der die Adresse kennt, Ihren SSH-Banner erreichen und mit Anmeldeversuchen beginnen. Onion-Adressen können über das Verzeichnissystem nicht aufgelistet werden. Die Adresse verhält sich daher wie ein Geheimnis. Sie kann aber auf gewöhnlichem Weg bekannt werden, etwa über die Shell-History oder Konfigurationsdateien, die in einem git-Repository versioniert wurden. Die Clientautorisierung schließt diese Lücke. Der Dienst veröffentlicht seinen Descriptor verschlüsselt für einen Client-Schlüssel. Wer nur die Adresse, aber keinen Schlüssel besitzt, kann den Dienst nicht einmal auffinden.

Generieren Sie auf dem Client ein x25519-Schlüsselpaar. Dies ist die Pipeline aus dem Leitfaden zur Clientautorisierung des Tor Project, mit einer Änderung.

openssl genpkey -algorithm x25519 -out /tmp/k1.prv.pem
grep -v " PRIVATE KEY" /tmp/k1.prv.pem | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.prv.key
openssl pkey -in /tmp/k1.prv.pem -pubout | grep -v " PUBLIC KEY" | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.pub.key

In der veröffentlichten Version dieser Zeilen wird base64pem -d verwendet. Eine Standardinstallation von Ubuntu enthält dieses Programm nicht. Der Befehl wird dann mit base64pem: command not found beendet. GNU base64 -d dekodiert denselben PEM-Inhalt. Verwenden Sie daher dieses Programm.

Installieren Sie auf dem Server den öffentlichen Schlüssel.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/ssh/authorized_clients
echo "descriptor:x25519:PASTE_PUBLIC_KEY_HERE" | sudo tee /var/lib/tor/ssh/authorized_clients/laptop.auth >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/ssh/authorized_clients/laptop.auth
sudo systemctl reload tor

Nur Dateien, die mit .auth enden, werden gelesen. Speichern Sie die Datei als laptop.auth.txt. Andernfalls ignoriert tor die Datei ohne ausgegebene Fehlermeldung, und der Dienst bleibt für jeden offen, der die Adresse kennt.

Installieren Sie auf dem Client den privaten Schlüssel. Unter Ubuntu wird der tor-Daemon als Benutzer debian-tor ausgeführt und kann keine Dateien in Ihrem Home-Verzeichnis lesen. Bewahren Sie das Verzeichnis daher an einem Ort auf, auf den dieser Benutzer zugreifen kann.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/onion_auth
echo "ADDRESS_WITHOUT_DOT_ONION:descriptor:x25519:PASTE_PRIVATE_KEY_HERE" | sudo tee /var/lib/tor/onion_auth/myvps.auth_private >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/onion_auth/myvps.auth_private
sudo chmod 600 /var/lib/tor/onion_auth/myvps.auth_private

Fügen Sie ClientOnionAuthDir /var/lib/tor/onion_auth zur /etc/tor/torrc des Clients hinzu und laden Sie tor neu. Wenn Sie tor stattdessen als Ihr eigener Benutzer ausführen, etwa beim Homebrew-Build unter macOS, setzen Sie ClientOnionAuthDir auf ~/.tor/onion_auth und verwenden Sie den Modus 0700.

Die Adresse in dieser Datei besteht aus den 56 Zeichen ohne das Suffix .onion. Löschen Sie /tmp/k1.prv.pem und /tmp/k1.prv.key, wenn Sie fertig sind.

Testen Sie nun beide Richtungen. ssh myvps sollte weiterhin eine Verbindung herstellen. Von einem Computer ohne Schlüssel sollte dieselbe Adresse fehlschlagen. Dieser Fehler bestätigt, dass die Autorisierung aktiv ist.

Port 22 in dieser Reihenfolge schließen

Richten Sie zuerst ein Sicherheitsnetz ein. Dieser eine Befehl macht beide folgenden Änderungen nach fünfzehn Minuten rückgängig, falls Sie sich aussperren.

sudo systemd-run --on-active=15m --unit=ssh-rescue \
  /bin/sh -c 'ufw allow 22/tcp; rm -f /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl restart ssh.socket'

Brechen Sie den Befehl mit sudo systemctl stop ssh-rescue.timer ab, sobald Sie bestätigt haben, dass die Onion-Route weiterhin funktioniert.

Beenden Sie als Nächstes das Listening von sshd auf der öffentlichen Adresse. Ubuntu 24.04 aktiviert SSH über eine Socket-Unit. Daher wird ListenAddress in sshd_config ignoriert: ssh.socket verwaltet den Listening-Socket, nicht sshd. Prüfen Sie, welcher Fall auf Ihrem System zutrifft.

systemctl is-enabled ssh.socket

Wenn die Ausgabe enabled enthält, führen Sie sudo systemctl edit ssh.socket aus und ergänzen Sie Folgendes.

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

Das leere ListenStream= löscht den von der Paket-Unit geerbten Wert. Wenn Sie diese Zeile weglassen, fügen Sie einen zweiten Listener hinzu, während der öffentliche Listener bestehen bleibt. Das ist der häufigste Grund dafür, dass dieser Schritt scheinbar ohne Fehlermeldung scheitert.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
ss -tlnp | grep ':22'

ss sollte 127.0.0.1:22 und auf 0.0.0.0:22 nichts anzeigen. Wenn ssh.socket deaktiviert war, tragen Sie ListenAddress 127.0.0.1 in /etc/ssh/sshd_config.d/10-onion.conf ein, führen Sie sudo systemctl restart ssh aus und prüfen Sie anschließend mit derselben ss-Zeile. Diese Ausgabe ist in beiden Fällen der Nachweis.

Anschließend folgt die Firewall. Dabei handelt es sich um die normale UFW-Regelverwaltung auf einem VPS. Führen Sie zuerst sudo ufw status numbered aus und löschen Sie die darin aufgeführte SSH-Regel.

sudo ufw status numbered
sudo ufw delete allow OpenSSH
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw status verbose

Lassen Sie ausgehenden Datenverkehr zu. Tor baut ausgehend Verbindungen zu Relays an Ports wie 443 und 9001 auf. Eine Standardrichtlinie mit Ablehnung ausgehenden Datenverkehrs verhindert daher den Tor-Bootstrap und beseitigt gleichzeitig Ihre einzige verbleibende Zugangsmöglichkeit. Die meisten Anbieter betreiben außerdem eine separate Netzwerk-Firewall im Control Panel. Schließen Sie Port 22 auch dort. Andernfalls bleibt der Port unabhängig von der Ausgabe von ufw erreichbar.

Wenn Docker auf diesem System läuft, prüfen Sie die veröffentlichten Ports, bevor Sie den Vorgang als abgeschlossen betrachten. Docker schreibt eigene Regeln in dieselben Tabellen und veröffentlicht Container-Ports direkt an ufw vorbei. Eine ufw-Deny-Richtlinie bildet daher nicht das vollständige Bild ab.

Vor dem Reboot testen

systemctl is-enabled tor@default
sudo reboot

Wenn der erste Befehl den Dienst nicht als aktiviert meldet, führen Sie vor dem Reboot sudo systemctl enable tor@default aus. Warten Sie zwei Minuten und führen Sie anschließend ssh myvps aus. Tor muss nach dem Booten den Bootstrap-Vorgang abschließen. Daher antwortet die Onion-Adresse erst einige Zeit nach dem Start der Maschine.

Wenn der Dienst nie wieder startet, öffnen Sie die Konsole und lesen Sie sudo journalctl -u tor@default -b. Dort werden Syntaxfehler in torrc oder ein Berechtigungsproblem für ein Verzeichnis ausgegeben. Sie können Änderungen an torrc auch vor ihrer Übernahme prüfen.

sudo -u debian-tor tor --verify-config

Was das im Vergleich zu einem WireGuard-Tunnel kostet

Im Vergleich zu einem WireGuard-VPN auf Ihrem eigenen VPS ist ein Onion Service langsamer und weniger vorhersehbar. Machen Sie sich die Nachteile bewusst, bevor Sie sich dafür entscheiden.

Latenz. Ein Client-Circuit besteht aus drei Relays. Die Serviceseite fügt weitere drei hinzu. Ihre Tastatureingaben durchlaufen daher ungefähr sechs zufällig ausgewählte Rechner auf der ganzen Welt. Beim interaktiven Tippen ist eine deutliche Verzögerung spürbar. Dateiübertragungen sind langsam. WireGuard fügt nur einen Hop hinzu. Messen Sie Ihren eigenen Fall mit time ssh myvps 'echo ok', weil der Wert davon abhängt, welchen Circuit tor erstellt hat. Er ändert sich, sobald tor einen anderen Circuit erstellt.

Ein Userspace-Daemon im kritischen Pfad. WireGuard läuft im Kernel und wird zusammen mit dem Netzwerk aktiviert. Tor ist ein Prozess, der starten, den Bootstrap-Vorgang abschließen und ein Guard-Relay erreichen muss, bevor irgendetwas funktioniert. Wenn dieser Vorgang fehlschlägt, benötigen Sie die Konsole des Providers.

Uhrgenauigkeit. Onion-Service-Deskriptoren werden für bestimmte Zeiträume veröffentlicht. Eine stark falsch gehende Uhr verhindert daher die Adressauflösung, ohne dass irgendwo eine eindeutige Meldung erscheint. timedatectl sollte System clock synchronized: yes melden.

Dafür erhalten Sie eine Erreichbarkeit, die nicht mehr davon abhängt, dass eine Firewall-Regel korrekt ist. Es gibt keinen Port, der gescannt werden kann, und kein Banner, das ausgelesen werden kann. Außerdem ist die Adresse selbst ein Public Key. Der Endpunkt weist seine Identität daher nach, bevor SSH überhaupt startet.

In der Praxis ist meist beides sinnvoll. Verwenden Sie WireGuard als täglichen Zugangsweg. Lassen Sie den Onion Service als Route aktiviert, die auch dann noch funktioniert, wenn die WireGuard-Konfiguration fehlerhaft ist. Dadurch bleibt nur ein UDP-Port offen und kein öffentlich erreichbarer SSH-Port. Nichts davon ersetzt die Absicherung von sshd selbst: Eine Authentifizierung ausschließlich per Schlüssel und ein Login ohne root bleiben wichtig, weil ein Onion Service den Netzwerkpfad schützt, aber nichts darüber hinaus.

Fehlerbilder und die dabei angezeigten Fehlermeldungen

Tor erreicht nie Bootstrapped 0%. Ausgehender Datenverkehr ist blockiert, oder die Systemzeit weicht stark ab. Prüfen Sie die Richtlinie für ausgehende Verbindungen mit sudo ufw status verbose und führen Sie anschließend timedatectl aus.

systemctl status tor meldet active (exited). Das ist unter Debian und Ubuntu normal. Lesen Sie stattdessen tor@default.

Der Descriptor wurde nicht gefunden. Tor gibt den erweiterten SOCKS-Fehler F0 zurück: „Onion Service Descriptor Can Not be Found“. Entweder wurde der Descriptor noch nicht veröffentlicht, was nach einem Reload kurze Zeit dauern kann, oder Tor läuft auf dem Server nicht.

F4, „Onion Service Missing Client Authorization“. Dem Client fehlt ein passendes .auth_private, das Tor verwenden kann. Prüfen Sie, ob ClientOnionAuthDir in torrc eingetragen ist, das Verzeichnis den Modus 0700 hat, der Dateiname mit .auth_private endet und debian-tor die Datei lesen kann.

F5, „Onion Service Wrong Client Authorization“. Der private Schlüssel passt nicht zur .auth-Datei auf dem Server. Ein abschließendes = oder ein zusätzliches Newline innerhalb der Base32-Zeichenfolge verursacht diesen Fehler.

nc: invalid option -- 'X'. GNU netcat ist installiert und nicht die OpenBSD-Variante. Führen Sie sudo apt install -y netcat-openbsd aus.

Could not resolve hostname. ssh hat eine normale DNS-Auflösung versucht. Dafür gibt es keine Antwort für .onion, daher wurde ProxyCommand nicht ausgeführt. Das Muster Host in ~/.ssh/config passt nicht zu dem von Ihnen eingegebenen Namen.

Permission denied (publickey). Der Tunnel hat funktioniert, und Tor ist fertig. Behandeln Sie dies als ein gewöhnliches Problem mit verweigertem Zugriff und publickey und beziehen Sie Tor nicht in die weitere Fehlersuche ein.

FAQ

Bedeutet ein Onion Service auf meinem VPS wirklich, dass keine offenen Ports vorhanden sind?

Ja, sobald sshd an 127.0.0.1 gebunden ist und die Firewall eingehenden Datenverkehr verwirft. Tor stellt eine ausgehende TCP-Verbindung zu einem Relay her. Ihre Sitzung läuft über dieses Relay zurück. Dadurch nimmt kein Prozess auf dem Server eine Verbindung an der öffentlichen Adresse an. Überprüfen Sie dies mit ss -tlnp auf dem Server und mit einem Portscan von einem anderen System aus. Vergessen Sie nicht die eigene Netzwerk-Firewall des Providers im Control Panel. Sie ist von ufw getrennt und muss ebenfalls geschlossen sein.

Bietet die .onion-Adresse allein ausreichende Sicherheit für SSH?

Nein. Die Adresse ist 56 Zeichen lang und kann aus dem Verzeichnissystem weder erraten noch aufgelistet werden. Sie verhält sich daher wie ein Geheimnis. Sie kann jedoch durch die Shell-History und Konfigurationsdateien offengelegt werden. Aktivieren Sie zusätzlich die v3-Clientautorisierung. Damit wird der Service-Descriptor für Ihren Client-Schlüssel verschlüsselt. Wer nur die Adresse kennt, erhält den erweiterten Fehler F4 und erreicht sshd überhaupt nicht.

Was passiert, wenn Tor nach einem Reboot nicht startet?

Sie verlieren den SSH-Zugriff vollständig, weil die Onion-Adresse dann der einzige Zugangsweg ist. Deshalb muss die Provider-Konsole getestet werden, bevor Sie Port 22 schließen. Tor benötigt nach dem Boot außerdem Zeit für den Bootstrap-Vorgang. Daher antwortet die Adresse später, als der Server auf Ping reagiert. Wenn sie nie antwortet, melden Sie sich über die Konsole an und lesen Sie sudo journalctl -u tor@default -b. Dort wird entweder ein Syntaxfehler in torrc oder ein Berechtigungsproblem bei /var/lib/tor/ssh ausgegeben.

Ist SSH über Tor langsamer als WireGuard?

Ja, deutlich. Eine Verbindung zu einem Onion Service durchläuft etwa sechs zufällig ausgewählte Relays. WireGuard verwendet dagegen nur einen verschlüsselten Hop direkt zu Ihrem Server. Die Eingabe reagiert verzögert, und Übertragungen sind langsam. Häufig wird WireGuard für die tägliche Arbeit verwendet. Der Onion Service bleibt als Notfallzugang bestehen, der auch bei einer fehlerhaften VPN-Konfiguration funktioniert.