Hoe Je Verbindt met je VPS via Tor

Anonymity · 8 min. leestijd

Kort antwoord: Je kunt SSH in twee richtingen via Tor routeren: je client richten op de lokale SOCKS-proxy van Tor om je eigen IP te verbergen voor de server, of de SSH-poort van de VPS publiceren als een Tor-onion-service zodat de server zelf nooit een op het clearnet bereikbare SSH-poort heeft. De twee kunnen gecombineerd worden zodat geen van beide uiteinden van de sessie ooit het open internet raakt. Verwacht aanzienlijk hogere latency dan bij een directe verbinding, dus behandel dit als een techniek voor beheertoegang bij interactief shellwerk, niet als transportmiddel voor grote bestandsoverdrachten.

Twee verschillende problemen, allebei 'SSH via Tor' genoemd

Mensen die zoeken naar tor vps toegang proberen meestal een van twee verschillende problemen op te lossen, en de setup verschilt afhankelijk van welk probleem van toepassing is. Het eerste is client-side: je wilt je eigen IP-adres verbergen voor de server, voor iedereen die je lokale netwerk in de gaten houdt, en voor iedereen die later een dagvaarding stuurt naar de verbindingslogs van de VPS-provider. Het tweede is server-side: je wilt dat de VPS zelf geen enkele SSH-poort heeft die vanaf het publieke internet bereikbaar is, zodat hij niet gevonden kan worden door een poortscanner, niet aangevallen kan worden door een credential-stuffing-bot, en niet gelokaliseerd kan worden via zijn luisterende dienst.

Dit sluit elkaar niet uit. Veel van de verwarring in forumdraden over ssh over tor komt voort uit het door elkaar halen van 'ik wil verbergen wie er verbindt' met 'ik wil verbergen waarmee er verbonden wordt'. Deze gids behandelt beide, te beginnen met de eenvoudigere client-side setup, dan de onion-service-aanpak voor de server, en vervolgens hoe je het resultaat hardent en welke prestaties je daadwerkelijk mag verwachten.

Client-side anonimiteit: je SSH-client routeert via Tor zodat de server (en iedereen die inkomende verbindingen logt) een Tor-exitnode of relay ziet, niet je echte IP
Server-side anonimiteit: sshd is alleen bereikbaar via een Tor-onion-adres, dus er is helemaal geen publiek IP:poort voor SSH

Methode 1: route je SSH-client via de SOCKS-proxy van Tor

Een draaiende Tor-client (de Tor-daemon, niet per se Tor Browser) biedt een lokale SOCKS5-proxy, standaard op 127.0.0.1:9050. Elke SOCKS-bewuste applicatie kan hierop gericht worden, en SSH zelf spreekt van nature geen SOCKS, dus heb je een kleine brug nodig. De twee gangbare aanpakken zijn torsocks, dat een commando omhult en de TCP-verbindingen ervan via de proxy dwingt, en een ProxyCommand-regel in je SSH-configuratie die de verbinding via een SOCKS-geschikte netcat leidt.

De snelste test is simpelweg: installeer tor, bevestig dat het draait, en voer dan torsocks ssh user@your-vps-ip uit. Als dat verbindt, wordt je SSH-sessie nu via een driehops Tor-circuit gerouteerd. Voor iets dat je dagelijks gebruikt, voeg je in plaats van elke keer torsocks te typen een Host-blok toe aan ~/.ssh/config, met een ProxyCommand-regel zoals nc -X 5 -x 127.0.0.1:9050 %h %p (met OpenBSD netcat) of connect -S 127.0.0.1:9050 %h %p (met de connect-proxy-tool). Zo werkt gewoon ssh myhost en gaat het altijd via Tor zonder dat je de wrapper hoeft te onthouden.

Controleer of Tor daadwerkelijk draait en luistert op 9050 voordat je SSH zelf gaat oplossen
torsocks ssh user@host is de snelste manier om te testen; een ProxyCommand in ~/.ssh/config is de duurzame manier om het dagelijks te gebruiken
Deze methode verbergt je IP voor de VPS en voor iedereen die de authenticatielogs leest, maar de SSH-poort zelf staat nog steeds open voor het publieke internet

Methode 2: publiceer SSH als een Tor-onion-service op de VPS

Als het doel is om het eigen IP-adres van de VPS volledig buiten beeld te houden voor beheertoegang, moet de server Tor draaien en sshd alleen als hidden service beschikbaar stellen. Installeer tor op de VPS en voeg twee regels toe aan torrc: HiddenServiceDir, wijzend naar een map waar Tor naar kan schrijven, en HiddenServicePort 22 127.0.0.1:22, wat Tor vertelt om verbindingen die binnenkomen op poort 22 van het onion-adres door te sturen naar de lokaal luisterende sshd. Herstart Tor, en het genereert de eerste keer dat het start een lange willekeurige .onion-hostnaam in die map.

Cruciaal: deze stap verwijdert alleen blootstelling als sshd ook is ingesteld om te binden aan 127.0.0.1 in plaats van de publieke interface van de VPS (ListenAddress 127.0.0.1 in sshd_config, gevolgd door een herstart van sshd). Als je die stap overslaat, blijft SSH zowel via het onion-adres als rechtstreeks op het publieke IP bereikbaar, wat het hele punt teniet doet. Zodra dat gedaan is, verbind je vanaf de clientkant met torsocks ssh [email protected] — er verschijnt nooit een publiek IPv4- of IPv6-adres voor SSH in een poortscan van de VPS.

Voeg HiddenServiceDir en HiddenServicePort 22 127.0.0.1:22 toe aan torrc, en herstart Tor
Bind sshd zelf alleen aan 127.0.0.1 — een onion-service voor een nog steeds publieke poort verbergt niets
Lees het gegenereerde hostname-bestand in de HiddenServiceDir om het .onion-adres te krijgen waarmee je verbindt
Verbind met torsocks ssh [email protected]; een kaal IP werkt helemaal niet meer voor SSH

Authenticatie vergrendelen zodra SSH alleen op .onion reageert

De poort verbergen vervangt niet het harden van de login. Gebruik ed25519-sleutelparen, schakel wachtwoordauthenticatie volledig uit (PasswordAuthentication no), en schakel root-login via SSH uit (PermitRootLogin no). Als de sleutel die je gebruikt om deze VPS te bereiken dezelfde is die je gebruikt voor je alledaagse accounts, wordt de anonimiteit die je met de onion-service wint ondermijnd zodra de fingerprint van die sleutel opduikt in een gelekte dataset of een Shodan-/Censys-scan die elders aan jouw naam gekoppeld is — genereer een aparte sleutel voor anonieme infrastructuur.

Eén ding dat in deze setup stilletjes ophoudt te werken: IP-gebaseerde tools zoals fail2ban. Omdat verbindingen bij sshd binnenkomen via het lokale Tor-proces, is het bronadres dat sshd logt voor elke inlogpoging, geslaagd of niet, altijd 127.0.0.1 — er is geen aanvaller-IP om te blokkeren. Dat is geen gat dat je met een workaround hoeft te dichten; authenticatie met alleen sleutels zonder wachtwoordfallback verwijdert al het brute-force-risico dat fail2ban probeert te beperken. Verwacht alleen niet dat de logs ervan iets betekenen in deze configuratie.

Alleen sleutelauthenticatie, ed25519, geen wachtwoordfallback
Een dedicated sleutelpaar per anonieme server, nooit hergebruikt van een persoonlijke machine
PermitRootLogin no, en een non-root account met sudo voor het eigenlijke werk
Vertrouw niet op fail2ban of IP-allowlisting zodra verkeer via Tor binnenkomt — het bron-IP in logs is altijd loopback

Wat de prestaties daadwerkelijk zijn

Een standaard Tor-circuit bestaat uit drie relays, en een onion-service-verbinding stapelt twee driehops-circuits achter elkaar (één van de client naar het Tor-netwerk, één van het Tor-netwerk naar de hidden service), dus round-trip-latency ligt gewoonlijk ergens tussen een paar honderd milliseconden en een paar seconden, met af en toe een piek wanneer een circuit opnieuw wordt opgebouwd. Interactief werk — configuratiebestanden bewerken, logs bekijken, een dienst herstarten — is bij die latency ruimschoots bruikbaar. Stel ServerAliveInterval in je SSH-configuratie in zodat inactieve sessies niet worden weggegooid door de extra hop, en verwacht af en toe een stilstand terwijl Tor een nieuw circuit kiest.

Wat niet goed werkt, is doorvoer. scp, rsync of alles wat gigabytes verplaatst, kruipt vergeleken met een directe verbinding, omdat Tor-circuits geoptimaliseerd zijn voor low-latency interactiviteit over veel kortlevende streams, niet voor aanhoudende bandbreedte. Gebruik voor daadwerkelijke gegevensoverdracht — back-ups, grote uploads — een direct versleuteld kanaal (gewone SSH/rsync over het publieke IP, of een WireGuard-tunnel) en bewaar het Tor-pad specifiek voor administratieve shell-toegang waar het verbergen van de verbinding zwaarder weegt dan snelheid.

Fouten die stilletjes de anonimiteit ondermijnen die je probeerde te bereiken

De meeste mislukkingen hier zijn niet exotisch — het zijn kleine configuratiegaten die een achterdeurtje open laten. Let op het volgende voordat je op de setup vertrouwt:

Geen van deze vereist geavanceerde tooling om te vermijden; ze vereisen simpelweg dat je één keer de daadwerkelijk luisterende poorten en het DNS-gedrag controleert, in plaats van aan te nemen dat de Tor-configuratie alleen al het werk deed.

sshd nog steeds gebonden aan de publieke interface naast de onion-service, waardoor de 'verborgen' poort ook vindbaar is via een gewone poortscan
Hostnamen buiten Tor resolven (een verdwaalde DNS-lookup, of een applicatie die de SOCKS-proxy negeert voor DNS) lekt naar welke host je op het punt staat te verbinden nog voordat de Tor-verbinding zelfs maar begint
Een ProxyCommand dat stilletjes terugvalt op een directe verbinding als Tor niet draait — configureer het om fail-closed te zijn, niet fail-open, zodat een dode Tor-daemon betekent dat er geen verbinding is, in plaats van een onbedoelde clearnet-verbinding
Een SSH-sleutel, terminalprompt of shellgeschiedenis hergebruiken die deze sessie elders terugkoppelt aan een niet-anonieme identiteit

SSH-toegangsmethoden vergeleken
Methode	Wat het verbergt	Typische extra latency	Opzetmoeite
Directe SSH over het clearnet	Niets buiten de eigen versleuteling van SSH	Geen	Geen
Client gerouteerd via de SOCKS-proxy van Tor	Je IP-adres, voor de server en zijn logs	Gemiddeld — ongeveer één Tor-circuit, ~300ms-1s	Laag — torsocks of een ProxyCommand-regel
SSH gepubliceerd als een Tor-onion-service	Het publieke IP van de VPS; geen open SSH-poort op het internet	Gemiddeld tot hoog — server-side circuit toegevoegd	Gemiddeld — wijzigingen aan torrc en sshd_config
Beide gecombineerd: client via Tor, server als onion-service	Beide uiteinden van de verbinding blijven volledig buiten het clearnet	Hoogst — twee onafhankelijke 3-hops-circuits	Gemiddeld

Veelgestelde vragen

Verzwakt SSH via Tor de versleuteling van SSH?+

Nee. SSH onderhandelt zijn eigen end-to-end versleutelde kanaal onafhankelijk van het transport dat het draagt. Tor voegt daar zijn eigen laag circuitversleuteling aan toe, dus het verkeer is dubbel versleuteld, niet enkelvoudig met iets zwakkers.

Is SSH via Tor te traag voor echt beheerwerk?+

Voor interactieve shellsessies — bestanden bewerken, logs bekijken, diensten herstarten — is de extra latency merkbaar maar hanteerbaar. Gebruik voor bulkoverdrachten zoals back-ups of grote uploads in plaats daarvan een directe of WireGuard-verbinding en bewaar het Tor-pad voor beheertoegang.

Kan ik fail2ban nog gebruiken als SSH alleen bereikbaar is via een onion-service?+

Niet echt zinvol. Verbindingen komen bij sshd binnen vanaf het lokale proces van Tor, dus elke inlogpoging wordt gelogd als afkomstig van 127.0.0.1. Vertrouw in plaats daarvan op authenticatie met alleen sleutels zonder wachtwoordfallback, want dat verwijdert het brute-force-risico dat fail2ban probeert te adresseren.

Heb ik naast Tor ook een VPN nodig voor VPS-toegang?+

Meestal niet. Een commerciële VPN voor Tor schakelen verplaatst vooral vertrouwen naar de VPN-provider zonder echte extra bescherming voor dit gebruiksscenario. Alleen Tor voor de SSH-sessie, of een WireGuard-tunnel wanneer latency zwaarder weegt dan routeren via het netwerk van Tor, dekt de praktische gevallen.

Moeten beide kanten Tor draaien, of alleen mijn laptop?+

Alleen je client hoeft Tor te draaien om je eigen IP te verbergen voor de server (Methode 1). Ook het IP van de server verbergen vereist dat de VPS eveneens Tor draait, met sshd gepubliceerd als een onion-service (Methode 2) — de twee setups zijn onafhankelijk en kunnen apart of samen gebruikt worden.

Klaar om offshore te gaan?

Geen KYC, geen e-mail — alleen een anonieme key en crypto. Deploy binnen ~55 seconden.

Configureer je VPS →