So verbinden Sie sich über Tor mit Ihrem VPS

Anonymity · 8 Min. Lesezeit

Kurzantwort: Sie können SSH in zwei Richtungen über Tor leiten: Ihren Client auf Tors lokalen SOCKS-Proxy zeigen lassen, um Ihre eigene IP vor dem Server zu verbergen, oder den SSH-Port des VPS als Tor-Onion-Service veröffentlichen, sodass der Server selbst nie einen im Clearnet erreichbaren SSH-Port hat. Beides lässt sich kombinieren, sodass kein Ende der Session je das offene Internet berührt. Rechnen Sie mit spürbar höherer Latenz als bei einer Direktverbindung, behandeln Sie dies also als Technik für interaktiven Admin-Zugriff, nicht als Transportweg für große Dateiübertragungen.

Zwei verschiedene Probleme, beide 'SSH über Tor' genannt

Wer nach Tor-VPS-Zugang sucht, versucht meist eines von zwei unterschiedlichen Problemen zu lösen, und das Setup unterscheidet sich je nachdem, welches zutrifft. Das erste ist clientseitig: Sie wollen Ihre eigene IP-Adresse vor dem Server verbergen, vor jedem, der Ihr lokales Netzwerk beobachtet, und vor jedem, der später die Verbindungsprotokolle des VPS-Anbieters per Vorladung einfordert. Das zweite ist serverseitig: Sie wollen, dass der VPS selbst überhaupt keinen vom öffentlichen Internet erreichbaren SSH-Port hat, sodass er von einem Portscanner nicht gefunden, von einem Credential-Stuffing-Bot nicht ins Visier genommen und nicht anhand seines lauschenden Dienstes geolokalisiert werden kann.

Das schließt sich nicht gegenseitig aus. Ein Großteil der Verwirrung in Forenthreads über SSH über Tor entsteht dadurch, dass 'ich will verbergen, wer sich verbindet' mit 'ich will verbergen, womit sich verbunden wird' vermischt wird. Dieser Guide deckt beides ab, beginnend mit dem einfacheren clientseitigen Setup, gefolgt vom Onion-Service-Ansatz für den Server, dann wie man das Ergebnis härtet und welche Performance tatsächlich zu erwarten ist.

Clientseitige Anonymität: Ihr SSH-Client leitet über Tor, sodass der Server (und jeder, der dessen eingehende Verbindungen protokolliert) einen Tor-Exit oder -Relay sieht, nicht Ihre echte IP
Serverseitige Anonymität: sshd ist nur über eine Tor-Onion-Adresse erreichbar, sodass es überhaupt keine öffentliche IP:Port für SSH gibt

Methode 1: SSH-Client über Tors SOCKS-Proxy leiten

Ein laufender Tor-Client (der Tor-Daemon, nicht zwingend Tor Browser) stellt einen lokalen SOCKS5-Proxy bereit, standardmäßig unter 127.0.0.1:9050. Jede SOCKS-fähige Anwendung kann darauf zeigen, und SSH selbst spricht kein SOCKS nativ, weshalb Sie eine kleine Brücke benötigen. Die zwei gängigen Ansätze sind torsocks, das einen Befehl umhüllt und dessen TCP-Verbindungen durch den Proxy erzwingt, sowie ein ProxyCommand-Eintrag in Ihrer SSH-Konfiguration, der die Verbindung durch ein SOCKS-fähiges Netcat leitet.

Der schnellste Test ist schlicht: Tor installieren, prüfen, dass es läuft, dann torsocks ssh user@ihre-vps-ip ausführen. Klappt das, läuft Ihre SSH-Session nun über eine dreistufige Tor-Circuit. Für etwas, das Sie täglich nutzen, fügen Sie stattdessen einen Host-Block in ~/.ssh/config hinzu, statt jedes Mal torsocks einzutippen, mit einer ProxyCommand-Zeile wie nc -X 5 -x 127.0.0.1:9050 %h %p (mit OpenBSD-Netcat) oder connect -S 127.0.0.1:9050 %h %p (mit dem connect-proxy-Tool). So funktioniert einfaches ssh meinhost und läuft immer über Tor, ohne dass Sie sich den Wrapper merken müssen.

Prüfen Sie zuerst, ob Tor tatsächlich läuft und auf 9050 lauscht, bevor Sie SSH selbst debuggen
torsocks ssh user@host ist der schnellste Weg zum Testen; ein ProxyCommand in ~/.ssh/config ist der dauerhafte Weg für den Alltag
Diese Methode verbirgt Ihre IP vor dem VPS und vor jedem, der dessen Auth-Logs liest, aber der SSH-Port selbst bleibt für das öffentliche Internet offen

Methode 2: SSH auf dem VPS als Tor-Onion-Service veröffentlichen

Wenn das Ziel ist, die eigene IP-Adresse des VPS für den Admin-Zugriff vollständig aus dem Spiel zu nehmen, muss der Server Tor ausführen und sshd nur als Hidden Service exponieren. Installieren Sie Tor auf dem VPS und fügen Sie dann zwei Zeilen zu torrc hinzu: HiddenServiceDir, das auf ein Verzeichnis zeigt, in das Tor schreiben kann, und HiddenServicePort 22 127.0.0.1:22, was Tor anweist, Verbindungen, die am Port 22 der Onion-Adresse ankommen, an den lokal lauschenden sshd weiterzuleiten. Starten Sie Tor neu, und es generiert beim ersten Start einen langen zufälligen .onion-Hostnamen in diesem Verzeichnis.

Entscheidend ist: Dieser Schritt entfernt die Exponierung nur, wenn sshd zusätzlich angewiesen wird, an 127.0.0.1 statt an die öffentliche Schnittstelle des VPS zu binden (ListenAddress 127.0.0.1 in sshd_config, dann sshd neu starten). Wird dieser Schritt übersprungen, bleibt SSH sowohl über die Onion-Adresse als auch direkt über die öffentliche IP erreichbar, was den Zweck zunichtemacht. Ist das erledigt, verbinden Sie sich clientseitig mit torsocks ssh [email protected] — bei einem Portscan des VPS taucht dann für SSH keine öffentliche IPv4- oder IPv6-Adresse mehr auf.

HiddenServiceDir und HiddenServicePort 22 127.0.0.1:22 zu torrc hinzufügen, dann Tor neu starten
sshd selbst nur an 127.0.0.1 binden — ein Onion-Service vor einem weiterhin öffentlichen Port verbirgt nichts
Die generierte Hostname-Datei im HiddenServiceDir auslesen, um die .onion-Adresse für die Verbindung zu erhalten
Mit torsocks ssh [email protected] verbinden; eine reine IP funktioniert für SSH danach überhaupt nicht mehr

Authentifizierung absichern, sobald SSH nur noch über .onion antwortet

Den Port zu verbergen ersetzt nicht das Härten des Logins. Nutzen Sie ed25519-Schlüsselpaare, deaktivieren Sie Passwort-Authentifizierung vollständig (PasswordAuthentication no) und deaktivieren Sie Root-Login über SSH (PermitRootLogin no). Wenn der Key, mit dem Sie diesen VPS erreichen, derselbe ist, den Sie für Ihre alltäglichen Konten nutzen, wird die durch den Onion-Service gewonnene Anonymität in dem Moment untergraben, in dem der Fingerprint dieses Keys in einem Breach-Dump oder einem Shodan-/Censys-Scan auftaucht, der anderswo mit Ihrem Namen verknüpft ist — generieren Sie einen dedizierten Key für anonyme Infrastruktur.

Eine Sache, die in diesem Setup unauffällig aufhört zu funktionieren: IP-basierte Tools wie fail2ban. Da Verbindungen über den lokalen Tor-Prozess bei sshd ankommen, ist die von sshd protokollierte Quelladresse bei jedem einzelnen Login-Versuch, ob erfolgreich oder nicht, 127.0.0.1 — es gibt keine Angreifer-IP zu sperren. Das ist keine Lücke, die Sie mit einem Workaround füllen müssen: Reine Key-Authentifizierung ohne Passwort-Fallback beseitigt bereits das Brute-Force-Risiko, gegen das fail2ban überhaupt existiert. Erwarten Sie nur nicht, dass dessen Logs in dieser Konfiguration aussagekräftig sind.

Nur Key-Auth, ed25519, kein Passwort-Fallback
Ein dediziertes Schlüsselpaar pro anonymem Server, niemals von einer persönlichen Maschine wiederverwendet
PermitRootLogin no, und ein Nicht-Root-Konto mit sudo für die eigentliche Arbeit
Verlassen Sie sich nicht auf fail2ban oder IP-Allowlisting, sobald der Traffic über Tor ankommt — die Quell-IP in den Logs ist immer Loopback

Wie die Performance tatsächlich aussieht

Eine Standard-Tor-Circuit besteht aus drei Relays, und eine Onion-Service-Verbindung stapelt zwei solcher dreistufigen Circuits End-to-End (eine vom Client in das Tor-Netzwerk, eine vom Tor-Netzwerk zum Hidden Service), sodass die Round-Trip-Latenz üblicherweise zwischen ein paar hundert Millisekunden und ein paar Sekunden liegt, mit gelegentlichen Spitzen, wenn eine Circuit neu aufgebaut wird. Interaktive Arbeit — Konfigurationsdateien bearbeiten, Logs prüfen, einen Dienst neu starten — ist bei dieser Latenz durchaus nutzbar. Setzen Sie ServerAliveInterval in Ihrer SSH-Konfiguration, damit inaktive Sessions nicht wegen des zusätzlichen Hops abgebrochen werden, und rechnen Sie mit gelegentlichen Aussetzern, während Tor eine neue Circuit wählt.

Was nicht gut funktioniert, ist Durchsatz. scp, rsync oder alles, was Gigabytes bewegt, kriecht im Vergleich zu einer Direktverbindung, weil Tor-Circuits auf latenzarme Interaktivität über viele kurzlebige Streams optimiert sind, nicht auf anhaltende Bandbreite. Für echte Datenübertragung — Backups, große Uploads — nutzen Sie einen direkten verschlüsselten Kanal (normales SSH/rsync über die öffentliche IP oder einen WireGuard-Tunnel) und reservieren Sie den Tor-Pfad speziell für administrativen Shell-Zugriff, bei dem das Verbergen der Verbindung wichtiger ist als Geschwindigkeit.

Fehler, die die angestrebte Anonymität still und leise zunichtemachen

Die meisten Fehlschläge hier sind nicht exotisch — es sind kleine Konfigurationslücken, die eine Seitentür offen lassen. Achten Sie auf Folgendes, bevor Sie dem Setup vertrauen:

Keiner dieser Punkte erfordert fortgeschrittenes Tooling zur Vermeidung; man muss nur einmal die tatsächlich lauschenden Ports und das DNS-Verhalten prüfen, statt anzunehmen, dass die Tor-Konfiguration allein schon alles erledigt hat.

sshd noch immer zusätzlich an der öffentlichen Schnittstelle gebunden, sodass der 'versteckte' Port auch durch einen einfachen Portscan auffindbar ist
Hostnamen außerhalb von Tor auflösen (ein versehentlicher DNS-Lookup, oder eine Anwendung, die den SOCKS-Proxy für DNS ignoriert) verrät, mit welchem Host Sie sich gleich verbinden werden, noch bevor die Tor-Verbindung überhaupt beginnt
Ein ProxyCommand, das stillschweigend auf eine Direktverbindung zurückfällt, wenn Tor nicht läuft — konfigurieren Sie es so, dass es fail closed statt fail open ist, sodass ein toter Tor-Daemon keine Verbindung bedeutet statt einer versehentlichen Clearnet-Verbindung
Wiederverwendung eines SSH-Keys, Terminal-Prompts oder Shell-Verlaufs, der diese Session zurück zu einer nicht-anonymen Identität anderswo verknüpft

SSH-Zugriffsmethoden im Vergleich
Methode	Was verborgen wird	Typische zusätzliche Latenz	Setup-Aufwand
Direktes SSH über das Clearnet	Nichts über SSHs eigene Verschlüsselung hinaus	Keine	Keiner
Client über Tors SOCKS-Proxy geleitet	Ihre IP-Adresse, vor dem Server und dessen Logs	Moderat — etwa eine Tor-Circuit, ~300ms-1s	Gering — torsocks oder eine ProxyCommand-Zeile
SSH als Tor-Onion-Service veröffentlicht	Die öffentliche IP des VPS; kein offener SSH-Port im Internet	Moderat bis hoch — serverseitige Circuit kommt hinzu	Mittel — Änderungen an torrc und sshd_config
Beide kombiniert: Client über Tor, Server als Onion-Service	Beide Enden der Verbindung bleiben vollständig außerhalb des Clearnets	Am höchsten — zwei unabhängige 3-Hop-Circuits	Mittel

FAQ

Schwächt SSH über Tor SSHs Verschlüsselung ab?+

Nein. SSH handelt seinen eigenen Ende-zu-Ende-verschlüsselten Kanal unabhängig vom Transportweg aus, der ihn trägt. Tor fügt seine eigene Circuit-Verschlüsselung obendrauf hinzu, sodass der Traffic zweifach verschlüsselt wird, nicht einfach mit etwas Schwächerem.

Ist SSH über Tor für echte Administrationsarbeit zu langsam?+

Für interaktive Shell-Sessions — Dateien bearbeiten, Logs prüfen, Dienste neu starten — ist die zusätzliche Latenz spürbar, aber handhabbar. Für Massentransfers wie Backups oder große Uploads nutzen Sie stattdessen eine Direkt- oder WireGuard-Verbindung und reservieren den Tor-Pfad für Admin-Zugriff.

Kann ich fail2ban weiter nutzen, wenn SSH nur über einen Onion-Service erreichbar ist?+

Nicht sinnvoll. Verbindungen kommen bei sshd über Tors lokalen Prozess an, sodass jeder Login-Versuch als von 127.0.0.1 kommend protokolliert wird. Verlassen Sie sich stattdessen auf reine Key-Authentifizierung ohne Passwort-Fallback, da dies das Brute-Force-Risiko beseitigt, gegen das fail2ban eigentlich helfen soll.

Brauche ich für VPS-Zugriff zusätzlich zu Tor auch ein VPN?+

Normalerweise nicht. Ein kommerzielles VPN vor Tor zu schalten verlagert das Vertrauen meist nur zum VPN-Anbieter, ohne echten zusätzlichen Schutz für diesen Anwendungsfall zu bieten. Tor allein für die SSH-Session, oder ein WireGuard-Tunnel, wenn Latenz wichtiger ist als das Routing über Tors Netzwerk, deckt die praktischen Fälle ab.

Müssen beide Enden Tor ausführen, oder nur mein Laptop?+

Nur Ihr Client muss Tor laufen lassen, um Ihre eigene IP vor dem Server zu verbergen (Methode 1). Auch die IP des Servers zu verbergen erfordert, dass der VPS ebenfalls Tor ausführt, mit sshd als veröffentlichtem Onion-Service (Methode 2) — die beiden Setups sind unabhängig voneinander und können getrennt oder zusammen genutzt werden.

Bereit für Offshore?

Kein KYC, keine E-Mail – nur ein anonymer Schlüssel und Krypto. Bereitgestellt in ~55 Sekunden.

VPS konfigurieren →