Adoro spiegare questo tipo di cose attraverso la visualizzazione. :-)
Pensa alle tue connessioni SSH come a tubi. Grandi tubi Normalmente, raggiungi questi tubi per eseguire una shell su un computer remoto. La shell funziona in un terminale virtuale (tty). Ma conosci già questa parte.
Pensa al tuo tunnel come a un tubo all'interno di un tubo. Hai ancora la grande connessione SSH, ma l'opzione -L o -R ti consente di impostare un tubo più piccolo al suo interno.
Ogni tubo ha un inizio e una fine. Il big tube, la tua connessione SSH, è iniziato con il tuo client SSH e finisce sul server SSH a cui ti sei connesso. Tutti i tubi più piccoli hanno gli stessi punti finali, tranne per il fatto che il ruolo di "inizio" o "fine" è determinato dal fatto che siano stati utilizzati -Lo -R(rispettivamente) per crearli.
(Non lo hai detto, ma suppongo che il computer "remoto" che hai citato, quello dietro il firewall, possa accedere a Internet usando Network Address Translation (NAT). Questo è un po 'importante, quindi si prega di correggere questo assunto se è falso.)
Quando si crea un tunnel, si specifica un indirizzo e una porta su cui risponderà e un indirizzo e una porta a cui verrà consegnato. L' -Lopzione indica al tunnel di rispondere sul lato locale del tunnel (l'host che esegue il client). L' -Ropzione indica al tunnel di rispondere sul lato remoto (il server SSH).
Quindi ... Per poter SSH da Internet in una macchina dietro un firewall, è necessario che la macchina in questione apra una connessione SSH al mondo esterno e includa un -Rtunnel il cui punto "entry" è il lato "remoto" di la sua connessione.
Dei due modelli mostrati sopra, vuoi quello a destra.
Dall'host con firewall:
ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com
Questo dice al tuo cliente di stabilire un tunnel con un -Rpunto di ingresso emote. Tutto ciò che si collega alla porta 22222 all'estremità del tunnel raggiungerà effettivamente la "porta localhost 22", dove "localhost" è dalla prospettiva del punto di uscita del tunnel (cioè il client ssh).
Le altre opzioni sono:
-f dice a ssh di mettersi in background dopo che si è autenticato, quindi non devi sederti in giro eseguendo qualcosa sul server remoto perché il tunnel rimanga attivo.-Ndice che si desidera una connessione SSH, ma in realtà non si desidera eseguire alcun comando remoto. Se tutto ciò che stai creando è un tunnel, l'inclusione di questa opzione consente di risparmiare risorse.-T disabilita l'allocazione pseudo-tty, il che è appropriato perché non stai cercando di creare una shell interattiva.
Ci sarà una sfida con la password a meno che tu non abbia impostato le chiavi DSA o RSA per un accesso senza password.
Si noti che si consiglia vivamente di utilizzare un account usa e getta (non il proprio accesso) che è stato impostato solo per questo tunnel / cliente / server.
Ora, dalla tua shell su yourpublichost , stabilisci una connessione all'host con firewall attraverso il tunnel:
ssh -p 22222 username@localhost
Riceverai una sfida chiave dell'host, poiché probabilmente non hai mai colpito questo host prima. Quindi riceverai una richiesta di password per l' usernameaccount (a meno che tu non abbia impostato le chiavi per l'accesso senza password).
Se accederai regolarmente a questo host, puoi anche semplificare l'accesso aggiungendo alcune righe al tuo ~/.ssh/configfile:
host remotehostname
User remoteusername
Hostname localhost
Port 22222
Regolare remotehostnamee remoteusernameadattarsi. Il remoteusernamecampo deve corrispondere al tuo nome utente sul server remoto, ma remotehostnamepuò essere qualsiasi nome host adatto a te, non deve corrispondere a nulla di risolvibile.
(Per esporre l'endpoint inverso su un IP non localhost , consulta questo post )
