Come Connettersi al Tuo VPS Su Tor

Anonymity · 8 min di lettura

Risposta rapida: Puoi instradare SSH attraverso Tor in due direzioni: puntare il tuo client verso il proxy SOCKS locale di Tor per nascondere il tuo IP dal server, oppure pubblicare la porta SSH del VPS come servizio onion Tor in modo che il server stesso non abbia mai una porta SSH raggiungibile sul clearnet. Le due modalità possono essere combinate in modo che nessuno dei due estremi della sessione tocchi mai internet aperta. Aspettati una latenza significativamente più alta rispetto a una connessione diretta, quindi trattala come una tecnica di accesso amministrativo per lavoro shell interattivo, non come un trasporto per grandi trasferimenti di file.

Due problemi diversi, entrambi chiamati 'SSH su Tor'

Chi cerca l'accesso vps tor sta di solito cercando di risolvere uno di due problemi distinti, e la configurazione differisce a seconda di quale si applica. Il primo è lato client: vuoi nascondere il tuo indirizzo IP dal server, da chiunque osservi la tua rete locale e da chiunque in seguito citi in giudizio i log di connessione del provider VPS. Il secondo è lato server: vuoi che il VPS stesso non abbia alcuna porta SSH raggiungibile dall'internet pubblica, così che non possa essere trovato da uno scanner di porte, preso di mira da un bot di credential-stuffing o geolocalizzato dal suo servizio in ascolto.

Questi obiettivi non si escludono a vicenda. Gran parte della confusione nei thread dei forum su ssh su tor deriva dal mescolare 'voglio nascondere chi si connette' con 'voglio nascondere a cosa ci si connette'. Questa guida copre entrambi, iniziando dalla configurazione lato client più semplice, poi l'approccio del servizio onion per il server, poi come rafforzare il risultato e quali prestazioni aspettarsi realmente.

Anonimato lato client: il tuo client SSH passa attraverso Tor così che il server (e chiunque registri le sue connessioni in entrata) veda un exit o relay Tor, non il tuo vero IP
Anonimato lato server: sshd è raggiungibile solo tramite un indirizzo onion Tor, quindi non esiste alcun IP:porta pubblico per SSH

Metodo 1: instrada il tuo client SSH attraverso il proxy SOCKS di Tor

Un client Tor in esecuzione (il demone Tor, non necessariamente Tor Browser) espone un proxy SOCKS5 locale, per default su 127.0.0.1:9050. Qualsiasi applicazione compatibile con SOCKS può essere puntata verso di esso, e SSH di per sé non parla SOCKS nativamente, quindi serve un piccolo ponte. I due approcci comuni sono torsocks, che avvolge un comando e forza le sue connessioni TCP attraverso il proxy, e una voce ProxyCommand nella tua configurazione SSH che instrada la connessione attraverso un netcat compatibile con SOCKS.

Il test più rapido è semplicemente: installa tor, verifica che sia in esecuzione, poi esegui torsocks ssh user@your-vps-ip. Se la connessione va a buon fine, la tua sessione SSH ora è instradata attraverso un circuito Tor a tre hop. Per qualcosa da usare quotidianamente, aggiungi un blocco Host a ~/.ssh/config invece di digitare torsocks ogni volta, usando una riga ProxyCommand come nc -X 5 -x 127.0.0.1:9050 %h %p (con OpenBSD netcat) o connect -S 127.0.0.1:9050 %h %p (con lo strumento connect-proxy). In questo modo un semplice ssh myhost funziona e passa sempre attraverso Tor senza che tu debba ricordare il wrapper.

Verifica che Tor sia effettivamente in esecuzione e in ascolto su 9050 prima di risolvere problemi di SSH stesso
torsocks ssh user@host è il modo più rapido per testare; un ProxyCommand in ~/.ssh/config è il modo duraturo per usarlo ogni giorno
Questo metodo nasconde il tuo IP dal VPS e da chiunque legga i suoi log di autenticazione, ma la porta SSH stessa resta aperta all'internet pubblica

Metodo 2: pubblica SSH come servizio onion Tor sul VPS

Se l'obiettivo è tenere l'indirizzo IP del VPS completamente fuori dal quadro per l'accesso amministrativo, il server deve eseguire Tor ed esporre sshd solo come servizio nascosto. Installa tor sul VPS, poi aggiungi due righe a torrc: HiddenServiceDir che punta a una directory su cui Tor può scrivere, e HiddenServicePort 22 127.0.0.1:22, che dice a Tor di inoltrare le connessioni in arrivo sulla porta 22 dell'indirizzo onion al sshd in ascolto localmente. Riavvia Tor, e alla prima esecuzione genera un lungo hostname .onion casuale in quella directory.

Fondamentalmente, questo passaggio riduce l'esposizione solo se anche sshd viene configurato per collegarsi a 127.0.0.1 invece che all'interfaccia pubblica del VPS (ListenAddress 127.0.0.1 in sshd_config, poi riavvia sshd). Saltare questo passaggio lascia SSH raggiungibile sia tramite l'indirizzo onion che direttamente sull'IP pubblico, il che vanifica lo scopo. Una volta fatto, connettiti dal lato client con torsocks ssh [email protected] — nessun indirizzo IPv4 o IPv6 pubblico per SSH comparirà mai in una scansione di porte del VPS.

Aggiungi HiddenServiceDir e HiddenServicePort 22 127.0.0.1:22 a torrc, poi riavvia Tor
Collega sshd stesso solo a 127.0.0.1 — un servizio onion davanti a una porta ancora pubblica non nasconde nulla
Leggi il file hostname generato all'interno di HiddenServiceDir per ottenere l'indirizzo .onion a cui connetterti
Connettiti con torsocks ssh [email protected]; un semplice IP non funzionerà più per SSH

Blindare l'autenticazione una volta che SSH risponde solo su .onion

Nascondere la porta non sostituisce il rafforzamento del login. Usa coppie di chiavi ed25519, disabilita completamente l'autenticazione via password (PasswordAuthentication no) e disabilita il login root via SSH (PermitRootLogin no). Se la chiave che usi per raggiungere questo VPS è la stessa che usi per i tuoi account quotidiani, l'anonimato ottenuto dal servizio onion viene compromesso nel momento in cui l'impronta di quella chiave compare in un dump di violazione dati o in una scansione Shodan/Censys collegata al tuo nome altrove — genera una chiave dedicata per l'infrastruttura anonima.

Una cosa che silenziosamente smette di funzionare in questa configurazione: strumenti basati su IP come fail2ban. Poiché le connessioni arrivano a sshd tramite il processo Tor locale, l'indirizzo sorgente che sshd registra è 127.0.0.1 per ogni singolo tentativo di login, riuscito o meno — non c'è un IP aggressore da bannare. Non è una lacuna da colmare con un workaround: l'autenticazione solo a chiave senza fallback via password elimina già il rischio di brute-force che fail2ban esiste per mitigare. Semplicemente non aspettarti che i suoi log siano significativi in questa configurazione.

Autenticazione solo a chiave, ed25519, nessun fallback via password
Una coppia di chiavi dedicata per ogni server anonimo, mai riutilizzata da una macchina personale
PermitRootLogin no, e un account non-root con sudo per il lavoro vero e proprio
Non fare affidamento su fail2ban o allowlisting IP una volta che il traffico arriva via Tor — l'IP sorgente nei log è sempre loopback

Come si presentano davvero le prestazioni

Un circuito Tor standard è composto da tre relay, e una connessione a servizio onion accumula due circuiti a tre hop da un capo all'altro (uno dal client verso la rete Tor, uno dalla rete Tor verso il servizio nascosto), quindi la latenza di andata e ritorno si colloca comunemente tra qualche centinaio di millisecondi e un paio di secondi, con picchi occasionali quando un circuito viene ricostruito. Il lavoro interattivo — modificare file di configurazione, controllare i log, riavviare un servizio — è pienamente utilizzabile a quella latenza. Imposta ServerAliveInterval nella tua configurazione SSH così le sessioni inattive non vengono interrotte dall'hop extra, e aspettati occasionali rallentamenti mentre Tor sceglie un nuovo circuito.

Ciò che non funziona bene è il throughput. scp, rsync o qualsiasi cosa sposti gigabyte procederà lentamente rispetto a una connessione diretta, perché i circuiti Tor sono ottimizzati per bassa latenza interattiva su molti flussi brevi, non per banda sostenuta. Per il trasferimento dati vero e proprio — backup, upload di grandi dimensioni — usa un canale crittografato diretto (semplice SSH/rsync sull'IP pubblico, o un tunnel WireGuard) e riserva il percorso Tor specificamente per l'accesso shell amministrativo dove nascondere la connessione conta più della velocità.

Errori che silenziosamente compromettono l'anonimato che stavi cercando di ottenere

La maggior parte dei fallimenti qui non è esotica — sono piccole lacune di configurazione che lasciano aperta una porta laterale. Attenzione a queste prima di fidarti della configurazione:

Nessuno di questi richiede strumenti avanzati per essere evitato; richiedono solo di controllare una volta le porte effettivamente in ascolto e il comportamento DNS, invece di presumere che la sola configurazione di Tor abbia fatto il lavoro.

sshd ancora collegato all'interfaccia pubblica insieme al servizio onion, così che la porta 'nascosta' sia anche trovabile con una semplice scansione di porte
Risolvere hostname al di fuori di Tor (una ricerca DNS vagante, o un'applicazione che ignora il proxy SOCKS per il DNS) rivela quale host stai per contattare prima ancora che la connessione Tor inizi
Un ProxyCommand che ricade silenziosamente su una connessione diretta se Tor non è in esecuzione — configuralo per fallire in modo chiuso, non aperto, così che un demone Tor spento significhi nessuna connessione invece di una accidentale sul clearnet
Riutilizzare una chiave SSH, un prompt del terminale o una cronologia della shell che ricolleghi questa sessione a un'identità non anonima altrove

Confronto tra metodi di accesso SSH
Metodo	Cosa nasconde	Latenza aggiuntiva tipica	Sforzo di configurazione
SSH diretto sul clearnet	Nulla oltre alla crittografia propria di SSH	Nessuna	Nessuno
Client instradato tramite il proxy SOCKS di Tor	Il tuo indirizzo IP, dal server e dai suoi log	Moderata — circa un circuito Tor, ~300ms-1s	Bassa — torsocks o una riga ProxyCommand
SSH pubblicato come servizio onion Tor	L'IP pubblico del VPS; nessuna porta SSH aperta su internet	Da moderata ad alta — aggiunto circuito lato server	Media — modifiche a torrc e sshd_config
Entrambi combinati: client via Tor, server come servizio onion	Entrambi gli estremi della connessione restano completamente fuori dal clearnet	Massima — due circuiti indipendenti a 3 hop	Media

FAQ

SSH su Tor indebolisce la crittografia di SSH?+

No. SSH negozia il proprio canale crittografato end-to-end in modo indipendente dal trasporto che lo veicola. Tor aggiunge il proprio livello di crittografia di circuito sopra, quindi il traffico è crittografato due volte, non una sola con qualcosa di più debole.

SSH su Tor è troppo lento per un lavoro amministrativo reale?+

Per le sessioni shell interattive — modificare file, controllare i log, riavviare servizi — la latenza aggiuntiva è percettibile ma gestibile. Per trasferimenti massivi come backup o upload di grandi dimensioni, usa invece una connessione diretta o WireGuard e riserva il percorso Tor per l'accesso amministrativo.

Posso ancora usare fail2ban se SSH è raggiungibile solo tramite un servizio onion?+

Non in modo significativo. Le connessioni arrivano a sshd dal processo locale di Tor, quindi ogni tentativo di login viene registrato come proveniente da 127.0.0.1. Affidati invece all'autenticazione solo a chiave senza fallback via password, poiché elimina il rischio di brute-force che fail2ban è pensato per affrontare.

Ho bisogno anche di una VPN oltre a Tor per l'accesso al VPS?+

Non di solito. Concatenare una VPN commerciale davanti a Tor per lo più sposta la fiducia verso il provider VPN senza aggiungere protezione reale per questo caso d'uso. Solo Tor per la sessione SSH, o un tunnel WireGuard quando la latenza conta più dell'instradamento attraverso la rete Tor, copre i casi pratici.

Entrambi gli estremi devono eseguire Tor, o solo il mio laptop?+

Solo il tuo client deve avere Tor in esecuzione per nascondere il tuo IP dal server (Metodo 1). Nascondere anche l'IP del server richiede che il VPS esegua Tor a sua volta, con sshd pubblicato come servizio onion (Metodo 2) — le due configurazioni sono indipendenti e possono essere usate separatamente o insieme.

Pronto ad andare offshore?

Niente KYC, niente email — solo una chiave anonima e crypto. Distribuisci in ~55 secondi.

Configura il tuo VPS →