Capitano sempre più spesso scenari in cui devi accedere a un dispositivo che si trova dietro DNS filtrati, un NAT o firewall aziendali che non permettono alcuna modifica alle regole di rete. Quando aprire porte o riconfigurare il firewall sul lato privato non è un'opzione, il reverse SSH tunneling diventa più che mai uno strumento essenziale per mantenere un accesso remoto sicuro e resiliente.

Immagina questa situazione: hai un client remoto (il tuo portatile o un altro dispositivo esterno) con accesso a Internet in uscita. Hai anche un server pubblico (cloud o VPS) con SSH esposto. Infine c'è un server privato o un dispositivo IoT nascosto dietro NAT e firewall, senza IP pubblico e senza accessi in ingresso consentiti. Il tuo obiettivo è raggiungere quel dispositivo privato passando attraverso il server pubblico, senza toccare la configurazione del firewall sul lato privato. Vediamo come funziona il reverse SSH tunneling.

Per prima cosa il dispositivo privato apre una connessione SSH in uscita verso il server pubblico, usando l'opzione -R. Per esempio:

ssh -R 12345:localhost:22 user@public-server.example.com

In questo comando:

  • -R dice a SSH di impostare un remote port forwarding (un tunnel "inverso").
  • 12345 è la porta che verrà aperta sul server pubblico.
  • localhost:22 si riferisce alla porta 22 (SSH) sul dispositivo privato.
  • user@public-server.example.com è il login SSH sull'host pubblico.

Una volta stabilita questa connessione, qualsiasi tentativo di collegarsi via SSH al server pubblico sulla porta 12345 viene inoltrato indietro attraverso il tunnel fino alla porta 22 del dispositivo privato. Puoi quindi eseguire:

ssh -p 12345 user@public-server.example.com

e collegarti al dispositivo privato come se fosse raggiungibile direttamente.

Schema di un tunnel SSH: client con applicazione e chiave SSH, tunnel cifrato attraverso Internet, server SSH e application server