Come gestire il tuo VPS tramite Tor

Hai comprato un server anonimo, pagato in Monero, e hai saltato il controllo dell'ID. Poi ti colleghi via SSH dal tuo IP di casa attraverso internet aperto — e consegni silenziosamente al tuo ISP, alla rete di transito e a chiunque osservi la macchina una linea netta che va dal tuo viso alla macchina. Se vuoi gestire un server tramite Tor, l'obiettivo è semplice: non lasciare mai che un pacchetto clearnet colleghi la tua posizione reale alla macchina che amministri. Questa guida copre i modi pratici per raggiungere e gestire un VPS interamente attraverso la rete Tor, e le fughe che lo annullano silenziosamente.

Tor ti dà due primitive utili per l'amministrazione. Puoi instradare la tua SSH in uscita attraverso Tor come client, così il tuo IP reale non tocca mai il server. Oppure puoi pubblicare il demone SSH stesso come servizio onion, così la macchina non ha alcuna porta di gestione esposta su clearnet. La maggior parte degli operatori attenti finisce per usarli entrambi insieme. Costruiremo dalla configurazione più semplice alla più robusta.

Perché gestire un server tramite Tor

Il provisioning anonimo copre solo la porta d'ingresso. Se ti registri senza KYC e paghi con un VPS senza KYC fatturato in Monero, il provider non ha nome o carta legati al tuo account — ma nel momento in cui accedi dalla tua connessione di casa, crei una nuova e continua traccia cartacea. Il tuo ISP vede connessioni ripetute a un IP di datacenter specifico. I log di autenticazione del server registrano l'indirizzo di origine di ogni sessione. Correla i due e l'anonimato per cui hai pagato svanisce.

Instradare il traffico di gestione attraverso Tor colma questa lacuna. Il tuo ISP vede solo che hai usato Tor; non può vedere quale server hai raggiunto. Il VPS vede un'uscita Tor (o un punto di rendezvous, per SSH onion), mai il tuo indirizzo. L'identità che hai tenuto fuori dal modulo di registrazione resta fuori dal filo, sessione dopo sessione.

Il modello di minaccia, detto chiaramente

Tor protegge il percorso di rete. Non igienizza la macchina, l'account o le tue abitudini operative. Prima di iniziare, sii chiaro su cosa stai effettivamente difendendo: un osservatore passivo sulla tua rete locale, la capacità del provider di correlare il tuo IP di gestione con la macchina, e i registri che sopravvivono alla sessione. Tor affronta tutti e tre. Non ti protegge non se incolli il tuo hostname reale in una configurazione, riutilizzi una chiave SSH già associata al tuo nome altrove, o esegui uno strumento che perde DNS risolvendo fuori dal tunnel. Mantieni il modello onesto e farai i giusti compromessi qui sotto.

Metodo 1 — SSH attraverso Tor con torsocks

Il modo più rapido per instradare un singolo comando attraverso Tor è torsocks, un wrapper che forza le chiamate di rete di un programma attraverso il proxy SOCKS locale di Tor (di solito 127.0.0.1:9050). Installa il client Tor sulla tua workstation, assicurati che il demone sia in esecuzione, quindi anteponi il tuo comando SSH:

torsocks ssh [email protected]

Il dettaglio cruciale è il DNS. Un ssh hostname ingenuo risolve il nome sulla tua macchina prima, tramite il tuo resolver normale — una classica perdita che dice al tuo ISP esattamente quale host stai per raggiungere, prima che Tor veda la connessione. torsocks intercetta getaddrinfo e spinge la risoluzione attraverso Tor, quindi la ricerca non tocca mai il tuo resolver locale. Connettersi a un IP grezzo evita del tutto la ricerca del nome ed è l'abitudine più sicura. In ogni caso, verifica: se vedi una query DNS per l'hostname del tuo server sulla tua rete, il tunnel non sta facendo il suo lavoro.

Metodo 2 — un ProxyCommand nella tua configurazione SSH

Per qualsiasi cosa tu faccia più di una volta, incorpora Tor in ~/.ssh/config così non puoi dimenticare il wrapper. Usando netcat con un proxy SOCKS, un blocco per host appare così:

Host ghost
  HostName 203.0.113.10
  User admin
  ProxyCommand nc -x 127.0.0.1:9050 -X 5 %h %p
  IdentitiesOnly yes
  IdentityFile ~/.ssh/ghost_ed25519

Ora ssh ghost dialoga sempre attraverso la porta SOCKS5 di Tor, e %h/%p sono passati al proxy — quindi la risoluzione del nome avviene all'uscita, non sulla tua macchina. Imposta IdentitiesOnly yes così il tuo client non invia ogni chiave del tuo agente al server (che è sia un'impronta che una piccola perdita). Dai a ogni macchina anonima la sua chiave dedicata che non è associata alla tua identità reale da nessun'altra parte, e disabilita l'autenticazione con password lato server così una credenziale indovinata è inutile.

Una particolarità che vale la pena conoscere: Tor aggiunge latenza e ogni nuovo circuito è un'uscita casuale fresca, quindi la digitazione interattiva può sembrare lenta e le sessioni di lunga durata occasionalmente cadono quando un circuito ruota. Eseguire il tuo lavoro dentro tmux o screen sul server significa che un circuito caduto ti costa una riconnessione, non la tua sessione.

Metodo 3 — esporre SSH come servizio onion

La postura più forte rimuove completamente la porta di gestione in chiaro. Invece di esporre la porta 22 a internet e proteggerla con firewall, esegui un servizio onion Tor sul VPS che inoltra a 127.0.0.1:22. Il demone SSH si lega quindi solo a localhost; nulla risponde sull'IP pubblico. Lo raggiungi a un indirizzo .onion, attraverso Tor, end-to-end.

Sul server, aggiungi un servizio onion al tuo torrc che punta alla porta SSH locale:

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

Riavvia Tor, leggi il file hostname generato per il tuo .onion v3, e connettiti da un client che instrada attraverso Tor:

torsocks ssh [email protected]

Questo ha due grandi vantaggi. Primo, non c'è una porta SSH esposta che internet possa scansionare, forzare o fingerprintare — gli attacchi automatici contro la porta 22 semplicemente non hanno nulla da colpire. Secondo, la posizione della macchina è nascosta al client e la posizione del client è nascosta alla macchina; il rendezvous avviene dentro Tor. Segui la documentazione attuale e autorevole del Progetto Tor sui servizi onion piuttosto che un vecchio blog, perché le direttive torrc esatte e i formati delle chiavi cambiano tra le versioni. Per un pannello di amministrazione, una dashboard privata o un remote Git, lo stesso schema si applica — pubblica la porta localhost come onion e raggiungila attraverso Tor. La nostra guida su come eseguire un servizio nascosto Tor su un VPS anonimo approfondisce questo aspetto.

Onion con autenticazione client: alzare l'asticella

Un indirizzo onion semplice è inindovinabile ma non veramente privato — chiunque venga a conoscenza del .onion può raggiungere il prompt di accesso. Tor supporta autorizzazione client, dove l'onion non completerà nemmeno un handshake a meno che il client che si connette presenti una chiave pre-condivisa. Aggiungi la chiave pubblica del tuo client alla directory authorized_clients del servizio e l'onion diventa invisibile a tutti gli altri: niente chiave, niente connessione, niente prompt. Per un endpoint di gestione che tocchi solo tu, questo trasforma "sicurezza tramite un indirizzo inindovinabile" in un vero cancello crittografico.

Perdite DNS e i dettagli che rovinano tutto

Il modo più comune in cui le persone perdono mentre pensano di essere anonime è il DNS. Se qualsiasi parte del tuo flusso di lavoro risolve il nome del server fuori da Tor, hai pubblicizzato il tuo obiettivo. Preferisci connetterti tramite IP o .onion; quando devi usare un hostname, assicurati che la risoluzione sia proxyata (torsocks, un ProxyCommand, o un'impostazione SOCKS a livello di app con DNS remoto abilitato). La spiegazione dell'EFF su cosa Tor fa e non nasconde è un buon controllo di realtà su dove finisce la protezione.

Alcune altre trappole che vale la pena nominare:

• Correlazione temporale. Accedere con un programma rigido da una singola identità Tor è un pattern. Raramente conta per il lavoro di amministrazione, ma sii consapevole che esiste.
• Log di autenticazione lato server. Anche attraverso Tor, il tuo VPS registra i metadati di connessione. Su una macchina che controlli, regola cosa SSH e il journal di sistema conservano. Abbina la gestione Tor a un VPS senza log così il livello operativo è minimizzato su entrambi i lati.
• Sessioni miste. Non gestire la macchina anonima in un terminale mentre un'altra finestra sulla stessa macchina chiama a casa account legati al tuo nome. Mantieni isolato il flusso di lavoro anonimo — una VM dedicata o un profilo utente è un'assicurazione economica.
• Orologio e locale. Copiare e incollare timestamp, hostname o il tuo nome utente locale nelle configurazioni e nei messaggi di commit riattacca silenziosamente la tua identità. Ripuliscili.

Mantenere la gestione anonima nel lungo periodo

L'anonimato non è una configurazione una tantum; è una disciplina che mantieni sessione dopo sessione. La catena regge solo se ogni anello regge: registrazione anonima senza KYC, pagamento in Monero così non c'è un registro di carte, una chiave SSH dedicata non legata al tuo nome, DNS che non esce mai dal tunnel e amministrazione esclusivamente tramite Tor o un onion autenticato. Rompi un singolo anello e gli altri non possono salvarti. Mantienili tutti e non c'è semplicemente alcun punto nel processo in cui la tua identità reale e il tuo server si incontrano.

HushVPS è legale offshore e minimizza i dati, non è una zona senza legge. Gestire la propria macchina attraverso Tor è una pratica di privacy normale; la nostra politica di utilizzo accettabile vieta comunque CSAM, malware e infrastruttura botnet, spam e DDoS.