Un percorso di gestione basato su Tor per il tuo VPS

01Proteggi l'amministrazione oltre al checkout

Ordinare un server tramite un browser protetto non protegge automaticamente una successiva sessione SSH. Un accesso diretto può rivelare il tuo indirizzo di origine al server e alle reti lungo il percorso. Decidi come funzionerà l'amministrazione prima della prima connessione, incluso l'accesso di emergenza se la rotta preferita fallisce.

Tor può nascondere l'IP diretto del client dalla destinazione, ma non è un rimedio per credenziali riutilizzate, dati di configurazione identificativi o ogni attacco di correlazione del traffico. Aggiunge anche latenza. L'obiettivo utile è un percorso di gestione coerente di cui comprendi il comportamento e che puoi verificare.

02Inizia con un client Tor locale funzionante

Un daemon Tor di sistema offre comunemente SOCKS su 127.0.0.1:9050, mentre Tor Browser usa comunemente 9150. Verifica la tua configurazione effettiva invece di presumere l'una o l'altra porta. L'applicazione deve inviare la sua connessione attraverso quel proxy; aprire Tor Browser non instrada ogni programma del computer.

Sui sistemi supportati, torsocks avvolge applicazioni come SSH e instrada le chiamate di rete supportate attraverso Tor. Verifica la configurazione con un indirizzo di esempio di sola documentazione sostituito dall'indirizzo reale del tuo server. Il comando seguente presuppone un daemon Tor di sistema in esecuzione e un account amministrativo dedicato.

torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]

03Rendi la rotta parte della configurazione di SSH

Per un uso regolare, una configurazione per host riduce la probabilità di dimenticare un wrapper. L'esempio seguente usa un'implementazione netcat con supporto proxy SOCKS5. Le implementazioni differiscono, quindi conferma le opzioni -x e -X nella versione installata e verifica se la risoluzione dei nomi host sia remota.

IdentitiesOnly limita le chiavi offerte al server; abbinalo a una chiave nuova usata per questo progetto. Controlla e conserva l'impronta della chiave host del server tramite un canale di provisioning fidato. Tor cambia il percorso di rete, ma l'autenticazione host di SSH è comunque essenziale.

Host silent-admin
    HostName 203.0.113.45
    User admin
    IdentityFile ~/.ssh/silentvps_ed25519
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

04Sposta SSH dietro un servizio onion

Un endpoint onion consente l'amministrazione senza una porta SSH raggiungibile pubblicamente ed evita di usare un'uscita Tor per questa connessione. Installa e configura Tor sul server, poi mappa una porta virtuale onion al servizio SSH locale. L'esempio è una configurazione iniziale; i percorsi dei servizi e i comandi variano in base alla distribuzione.

Dopo che Tor crea la directory del servizio, recupera privatamente il suo file hostname e prova una connessione attraverso il proxy del tuo client. Mantieni private le chiavi di identità del servizio onion. Solo dopo un accesso indipendente riuscito dovresti limitare SSH a localhost e rimuovere l'accesso pubblico. Verifica che la tua console di recupero funzioni prima di apportare tale modifica.

HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22

05Aggiungi l'autorizzazione del client per un endpoint privato

Senza autorizzazione aggiuntiva, chiunque venga a conoscenza dell'indirizzo onion può raggiungere il servizio e il suo SSH prompt. L'autorizzazione client Tor v3 aggiunge una barriera crittografica separata: il servizio possiede la chiave pubblica del client autorizzato e il client detiene la chiave privata corrispondente.

Segui le istruzioni attuali del Tor Project per i formati delle chiavi e la directory authorized_clients. Verifica che un client non autorizzato non possa connettersi. Mantieni anche l'autenticazione con chiave SSH e pianifica come revocare l'autorizzazione di un dispositivo smarrito senza perdere il tuo accesso rimanente.

06Testa DNS ed evita la fuga di identità

Una risoluzione di nome host effettuata dal resolver locale può rivelare il tuo obiettivo prima che la connessione raggiunga il proxy. Usare l'IP del server per una destinazione clearnet evita quella particolare risoluzione; i nomi onion richiedono la risoluzione all'interno di Tor. Per altri nomi host, conferma il comportamento remote-DNS dell'applicazione invece di affidarti a un'impostazione proxy generica.

Il sistema guest può comunque conservare timestamp di autenticazione, nomi utente e voci di journal. Esamina intenzionalmente la loro conservazione invece di disabilitare ciecamente ogni diagnostica. Ispeziona anche i nomi host locali, i metadati dei commit e la configurazione copiata per dettagli identificativi. Tor non rimuove questi elementi dal traffico applicativo.

• Usa una chiave dedicata e un flusso di lavoro di progetto isolato.
• Verifica la porta SOCKS prevista e il comportamento remote DNS atteso.
• Mantieni l'accesso di recupero e un secondo login testato prima di modificare i listener.
• Rivedi il servizio Tor e SSH dopo gli aggiornamenti.
• Non condividere mai le chiavi di identità onion o i segreti di autorizzazione client.

07Mantieni pratiche le sessioni lunghe e la manutenzione futura

Esegui lavori amministrativi lunghi dentro tmux o screen così un'interruzione della connessione non distrugge la sessione. I circuiti Tor e le condizioni di rete possono cambiare, quindi mantieni i comandi ripetibili e comprendi come riprenderli. Una piccola quantità di latenza extra è più facile da tollerare quando la manutenzione è pianificata.

Lo stesso pattern onion può fare da frontend a una dashboard locale o a un servizio Git privato. Ogni applicazione necessita comunque di autenticazione, aggiornamenti software e configurazione accurata. Continua a usare la rotta protetta per supporto, rinnovo e backup dove i tuoi requisiti di privacy lo richiedono; la coerenza conta quanto la configurazione iniziale.