SSH remoto su una VPN: cosa non fa il tunnel

Una VPN dà a un server SSH un percorso privato ed elimina la necessità di un ascoltatore pubblico sulla porta 22. Non autentica l'host, non autorizza l'utente e non decide quali account possono accedere. Quello resta compito di SSH. Se una VPN sia il modo giusto per raggiungere il server dipende da tre condizioni, e il tunnel è solo una delle risposte possibili.

Cosa cambia il tunnel e cosa decide ancora SSH

Il tunnel cambia la raggiungibilità: quali indirizzi sono raggiungibili e da dove. Non cambia ciò che accade dopo l'arrivo della connessione TCP, dove il server presenta una chiave host e chiede un'identità utente.

Tieni i due livelli separati nella testa e nella documentazione. Un accesso VPN dimostra chi può usare la rete. Non dice nulla su quali account esistono sul target, e non è il permesso di accedere a ogni macchina raggiungibile.

Anche le modalità di errore sono separate, ed è questo che rende la separazione utile durante un incidente.

Tre condizioni che decidono il modello di accesso

Primo, il server deve essere raggiungibile da persone esterne alla tua rete? Se no, un percorso privato più un bastione o una mesh è il progetto più piccolo. Secondo, la popolazione dei client può davvero eseguire il client VPN, compresi quelli su dispositivi gestiti con restrizioni?

Terzo, ti serve un controllo per servizio o un controllo per utente? Una VPN concede la portata di rete; SSH concede l'accesso all'account. Se il requisito è che un appaltatore raggiunga un host e nient'altro, è un requisito di autorizzazione e il solo tunnel non può esprimerlo.

Rispondi a queste tre e il modello si sceglie da solo. Saltale e finirai per esporre SSH pubblicamente per evitare il rollout del client.

Conferma il percorso privato prima di dare la colpa a SSH

Connettiti alla VPN approvata e usa il nome o l'indirizzo privato documentato del target. Poi controlla la route selezionata, il permesso del gateway e il percorso di ritorno verso il client. Un nome che si risolve correttamente non è prova che l'indirizzo prenda il tunnel previsto, perché prefissi locali e remoti sovrapposti possono inviare la richiesta altrove del tutto. Quella distinzione merita di essere scritta nel runbook.

Se la connessione non arriva mai, verifica che il server sia in ascolto sull'interfaccia che ti aspetti e che il suo firewall host consenta l'origine che vede davvero. Un NAT del gateway può riscrivere quell'origine, quindi un elenco di autorizzazioni scritto per l'indirizzo del tunnel del client potrebbe non corrispondere mai.

Quella discrepanza è il guasto SSH autoinflitto più comune su una VPN.

Leggi la fase di errore, non l'errore combinato

Tre fasi producono tre messaggi diversi, e solo uno di essi riguarda le credenziali.

Usa l'errore esatto e il registro del server stesso invece di reimpostare insieme le credenziali VPN e SSH. Reimpostare entrambe è il modo in cui una diagnosi di cinque minuti diventa un incidente di identità di due giorni.

L'output dettagliato mostra quale fase hai raggiunto:

ssh -vv [email protected]

Mantieni intatte le chiavi host e l'autorizzazione

Convalida la chiave host tramite il processo fidato previsto, soprattutto dopo la sostituzione di un server. Un avviso inatteso di chiave cambiata è l'unico messaggio che non devi scartare solo perché la VPN si è connessa, perché un tunnel privato non rende la destinazione la macchina che pensi. Controlla l'impronta rispetto a una fonte di cui ti fidi indipendentemente dalla connessione.

Lato server, conferma che l'account sia autorizzato e che il metodo di autenticazione configurato sia quello offerto. Una chiave presente ma ignorata è di solito un problema di permessi o di configurazione, non di rete.

Limita l'accesso ai servizi alle identità necessarie e mantieni un percorso di ripristino autorizzato per le modifiche di rete.