Chi vede davvero la tua password SSH su una VPN non affidabile?

Fai passare una sessione SSH su una VPN che non gestisci tu, e la password appartiene ancora al server SSH, non alla rete in mezzo. Se il trasporto verso un host verificato è protetto a dovere, un osservatore passivo su quel percorso non ottiene la password in forma leggibile. Ma cambia una condizione e la risposta cambia: un host non verificato, un elenco di cifrari indebolito o una postazione compromessa producono esiti diversi. Esegui i controlli qui sotto in ordine e tratta ciascuno come condizione di arresto.

Nomina il destinatario prima di digitare qualsiasi cosa

Il campo della password viaggia dentro un messaggio di autenticazione, e quel messaggio viaggia dentro il trasporto cifrato. La riservatezza è una proprietà del trasporto, il che significa che dipende dall’aver negoziato una protezione e dall’averla negoziata con l’host che intendevi. È proprio questa seconda metà che le persone saltano. Una connessione cifrata verso un impostore è riservata e inutile allo stesso tempo. L’accesso alla VPN non dimostra nulla sull’host SSH, e la reputazione del fornitore non sostituisce il controllo della chiave.

Tieni separate le due direzioni nella testa. La chiave dell’host risponde a quale server hai raggiunto. L’autenticazione con password o chiave risponde a quale utente il server accetta. Migliorare la seconda non ripara mai la prima.

Controlla l’identità dell’host, il record e la negoziazione

Parti sul client con il record che già possiedi. Un’impronta pubblicata confrontata con una fonte attendibile, e una voce di known_hosts che corrisponde ancora, ti danno l’unica prova che conta prima che inizi l’autenticazione.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

Lato server, stampa le impronte che intendi pubblicare invece di copiarle a memoria. Distribuirle fuori dal canale è tutto il punto; un’impronta incollata dallo stesso canale di chat del nome host dimostra solo che entrambi vengono dallo stesso posto.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Gli algoritmi negoziati derivano dall’intersezione delle due parti. Se una configurazione client fissa uno scambio di chiavi obsoleto per raggiungere un dispositivo vecchio, quella scelta vale per ogni host con cui parla, quindi limitarla a quell’host invece che globalmente.

Leggi i metodi che il server accetta davvero

Sapere quali metodi di autenticazione un server consente ti dice a cosa serve la password. Un host che accetta solo chiavi pubbliche non ha scambi di password da proteggere, e un host che accetta ancora password merita una decisione deliberata invece di un valore predefinito ereditato.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Passare un utente all’autenticazione con chiave toglie la password di quell’utente da quello scambio. Non rende sicura una postazione compromessa e non rende innocua una sessione remota non affidabile. Sono rischi diversi con controlli diversi. Decidi anche sull’inoltro dell’agente. Inoltrare un agente verso un host non affidabile dà a quell’host la capacità di usare le tue chiavi finché dura la sessione, ed è un’esposizione maggiore della questione della password con cui è iniziato tutto.

Tratta un avviso di chiave dell’host come un passo di incidente

Quando il client avvisa che l’identificazione dell’host è cambiata, fermati e verifica tramite un canale che non passa sullo stesso percorso di rete. Confronta l’impronta con la console del server o con l’operatore che l’ha ricostruito. Cancellare la voce vecchia per zittire l’avviso è l’unica azione da rifiutare. Getta via la prova e trasforma una possibile intercettazione in un accesso normale.

Se l’host è stato ricostruito legittimamente, rimuovi la voce obsoleta solo dopo la conferma della nuova impronta, poi riconnettiti e ricontrolla la negoziazione. Registra il cambiamento con la data e il motivo, perché la prossima persona vedrà lo stesso avviso e deve sapere che è stato risolto.

Cosa non copre questa guida

Un operatore VPN che osserva il traffico non è la stessa cosa di un software con privilegi locali sulla tua macchina. La compromissione dell’endpoint, un’estensione del browser ostile o un keylogger stanno sotto tutto ciò che SSH può negoziare, e nessun tunnel cambia questo. Se la postazione è sospetta, segui la procedura di incidente invece di testare la segretezza riconnettendoti da un’altra uscita. Riconnettersi dimostra che il percorso di rete è cambiato e nulla sull’endpoint.

Chiudi con il caso ordinario: host verificato, trasporto protetto, il metodo di autenticazione che hai scelto apposta e nessun inoltro di cui non avevi bisogno. Quella combinazione è la risposta alla domanda del titolo, e sono quattro decisioni invece di una.