SSH su un secondo percorso privato mentre la VPN resta attiva

Una macchina raggiunge un'altra tramite VPN, e ora qualcuno vuole la stessa shell sulla rete privata di un provider. La rotta esiste, il ping riesce, eppure SSH rifiuta. La causa abituale è che il demone non ha mai ascoltato sul nuovo indirizzo, quindi non c'è nulla a cui connettersi. Questo è un problema di associazione dell'indirizzo prima che di firewall.

Perché una nuova rotta non crea un nuovo listener

Un socket in ascolto viene creato da un processo che indica gli indirizzi su cui accetterà connessioni. Una rotta dice solo ai pacchetti dove viaggiare; non crea un listener a destinazione. Quando sshd è configurato con un solo ListenAddress, le connessioni verso qualsiasi altro indirizzo locale vengono rifiutate anche se l'interfaccia è attiva. Lo stesso vale per un'unità socket che possiede la porta, ed è per questo che il primo controllo è sempre ciò che sta effettivamente ascoltando.

Confronta i due percorsi per indirizzo di destinazione, non per nome dell'interfaccia. Un client si connette a un indirizzo, e quell'indirizzo deve essere associato prima che qualsiasi regola del firewall conti.

Elenca gli indirizzi e i listener

Prima di modificare qualcosa, registra gli indirizzi sull'host e i socket esistenti in questo momento.

ip -br addr
ss -ltnp | grep ':22'

L'elenco degli indirizzi mostra quale indirizzo privato è reale e su quale interfaccia, mentre l'elenco dei socket mostra se qualcosa è associato ad esso. Un listener su 0.0.0.0:22 accetta già ogni indirizzo, quindi una nuova associazione non aggiunge nulla. Un listener su un indirizzo specifico spiega subito il rifiuto. Se la porta appartiene a un'unità socket invece che al demone, la configurazione del demone non è tutta la storia.

Aggiungi l'associazione e mantieni quella vecchia

OpenSSH accetta diverse voci ListenAddress, quindi il percorso VPN può restare mentre si aggiunge quello privato. Verifica il file prima di ricaricarlo.

sshd -t
systemctl reload sshd

Un test di configurazione fallito lascia il demone in esecuzione intatto, ed è esattamente ciò che vuoi mentre sei connesso tramite il percorso che stai modificando. Mantieni la voce esistente, aggiungi il nuovo indirizzo locale e conferma che il servizio si ricarichi senza interrompere la sessione corrente. Nelle installazioni attivate da socket, aggiungi l'indirizzo all'unità socket e ricarica quell'unità. Poi rileggi l'elenco dei listener, perché un'associazione che non è mai comparsa significa che è stato modificato il componente sbagliato.

Verifica la nuova sessione prima di chiudere quella vecchia

Connettiti al nuovo indirizzo mentre la sessione originale è ancora aperta, usando l'output dettagliato per vedere quale indirizzo e quale chiave sono stati usati. Lascia aperta la sessione originale finché la verifica non riesce due volte.

ssh -v [email protected]

Leggi le righe di debug per l'indirizzo di destinazione e la chiave host presentata. Conferma l'impronta della chiave host rispetto a un valore di cui ti fidi già, invece di accettare una chiave sconosciuta perché la rete è descritta come privata. La nuova destinazione richiede una propria voce known_hosts, e questo è previsto. Solo quando il percorso privato funziona si dovrebbe chiudere la vecchia sessione di gestione.

SSH protegge il trasporto, ma non rende due reti equivalenti di per sé. Decidi se la fiducia del transito privato è adeguata ai dati prima di farvi affidamento.