ssh -N -R *:sPort:dHost:dPort user@server

Ecco a voi uno dei comandi “definitivi” per lavorare con reti su linux: il comando per fare ssh reverse tunneling.

Ma a cosa serve ssh reverse tunneling?

SSH reverse tunneling permette di collegarsi ad un server remoto (dotato di servizio ssh) e dirgli di inviare/inoltrare tutte le connessioni TCP ricevute su una porta, ad un altro host in rete.

Vediamo un esempio per rendere l’idea.
Ammettiamo di avere un computer collegato dietro una NAT, ad esempio come accade per i clienti Fastweb. Questo computer avrà quindi un IP privato e non potrà quindi ricevere connessioni in ingresso da Internet.
Ammettiamo però di avere anche accesso SSH ad un server esterno alla rete Fastweb, dotato di normale indirizzo IP pubblico, ed in grado di ricevere connessioni in ingresso da Internet.

Se desideriamo aprire un server web (tipo apache o nginx) sul nostro computer collegato a Fastweb e renderlo accessibile da Internet, possiamo sfruttare il nostro server esterno tramite questo comando di ssh reverse tunneling:

ssh -Nt -R *:8000:localhost:80 user@server

In questo modo il nostro pc dietro NAT si collegherà al server esterno “server” mediante SSH e gli dirà di inoltrare tutte le connessioni in ingresso sulla porta TCP 8000 del server a noi che stiamo eseguendo il comando di tunneling. Noi poi inoltreremo la connessione al computer locale (cioè il “localhost” nel comando), sulla porta 80.
La comunicazione tra server esterno e noi sarà inoltre cifrata mediante SSH e quindi sicura.
Il risultato sarà che un utente, visitando http://server:8000/ si connetterà  al nostro computer dietro NAT.

Esistono ovviamente anche altre alternative per ottenere lo stesso risultato (ex: sfruttare una VPN e regole di routing), tuttavia questo comando è molto comodo per configurare velocemente setup temporanei, per fare debugging di problemi di rete o altro.

Dettagli del comando:

Passiamo ora ad analizzare la struttura del comando:

• L’opzione “N” specifica al client SSH chiamante che non è necessario accedere a una shell, ma si desidera esclusivamente redirezionare una connessione. L’assenza di questa opzione non comporta problemi, ma solo la “scomodità” che oltre al forwarding venga aperta una shell verso il server.
• “R” specifica che si desidera effettuare un reverse tunneling.
• “*:sPort:dHost:dPort” digitato dopo “-R” specifica come deve essere applicato il tunneling, ovvero che tutte le connessioni in ingresso a qualunque degli indirizzi IP  del server (ovvero “*”) sulla porta TCP sPort dovranno essere redirezionate al client SSH, e quindi a dHost sulla porta TCP dPort.
• “user@server” specifica che ci vogliamo collegare al server SSH “server” come utente “utente”.

Consigli:

• Affinchè il server permetta di inoltrare connessioni in ingresso, è necessario che sia presente l’opzione “GatewayPorts yes” all’interno del file /etc/ssh/sshd_config . Assicuriamoci che ci sia.
• In molti casi, a causa del NAT, può accadere che se il reverse tunnel resta inattivo per un po’ di tempo la connessione venga chiusa. In questo caso ci conviene aggiungere queste due righe al /etc/ssh/sshd_config del server:
  ClientAliveInterval 60
  
  ClientAliveCountMax 3

  Questo specifica che se la connessione rimane inattiva il server invia al client un messaggio di ping ogni 60 secondi per assicurarsi che sia ancora online e mantenere attività sulla connessione. Se l’host non risponde per tre volte la connessione viene chiusa.

• Potrebbe essere necessario in alcuni casi mandare in background il reverse tunnel appena creato, in questo caso basterà aggiungere una “f” al comando, ad esempio “ssh -Nf -R *:8000:localhost:80 user@server”
• Non a caso nell’esampio abbiamo utilizzato la porta 8000 per il binding sul server. Infatti dobbiamo ricordare che su GNU/Linux, le porte da 0 a 1024 sono porte TCP “well-known” ed è necessario avere privilegi di root per poterle utilizzare. Quindi a meno che l’utente “user” che stiamo utilizzando sull’host remoto sia “root”, dobbiamo scegliere porte dalla 1025 in su.
• Va ricordato che SSH reverse tunneling è possibile solo per connessioni TCP. UDP non è supportato.
  Per chi volesse forwardare UDP consiglio di utilizzare una VPN e procedere mediante routing e regole iptables.