Come funziona il tunneling SSH inverso?

Mi piace spiegare questo genere di cose attraverso la visualizzazione. 🙂

Pensa alle tue connessioni SSH come a valvole. Grandi tubi. Normalmente, raggiungerai questi tubi per eseguire una shell su un computer remoto. La shell viene eseguita in un terminale virtuale (tty). Ma conosci già questa parte.

Pensa al tuo tunnel come a un tubo allinterno di un tubo. Hai ancora la connessione SSH grande, ma lopzione -L o -R ti consente di impostare un tubo più piccolo al suo interno.

Ogni tubo ha un inizio e una fine. Il tubo grande, la tua connessione SSH, iniziata con il tuo client SSH e finisce al server SSH a cui ti sei connesso. Tutti i tubi più piccoli hanno gli stessi endpoint, tranne che il ruolo di “inizio” o “fine” è determinato dal fatto che tu abbia usato -L o -R (rispettivamente) per crearli.

(Non hai detto, ma presumo che la macchina “remota” che hai “menzionato, quella dietro il firewall, può accedere a Internet utilizzando NAT (Network Address Translation). Questo è abbastanza importante, quindi correggi questa ipotesi se è falsa.)

Quando crei un tunnel, specifichi un annuncio abito e porto su cui risponderà, indirizzo e porto a cui verrà consegnato. Lopzione -L dice al tunnel di rispondere sul lato locale del tunnel (lhost che esegue il client). Lopzione -R indica al tunnel di rispondere dal lato remoto (il server SSH).

Quindi … Per essere in grado di SSH da Internet in una macchina dietro un firewall, è necessario che la macchina in questione apra una connessione SSH con il mondo esterno e includa un -R tunnel il cui punto di” ingresso “è il lato” remoto “della sua connessione.

Dei due modelli mostrati sopra, vuoi quello a destra.

Dallhost protetto da firewall:

ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com 

Questo dice al tuo client di stabilire un tunnel con una voce di emote -R punto. Tutto ciò che si collega alla porta 22222 allestremità del tunnel raggiungerà effettivamente “localhost port 22”, dove “localhost” è dal punto di vista del punto di uscita del tunnel (cioè il tuo client ssh).

Le altre opzioni sono:

• -f dice a ssh di eseguire lo sfondo dopo lautenticazione, quindi non devi sederti a eseguire qualcosa sul server remoto affinché il tunnel rimanga attivo.
• -N dice che vuoi una connessione SSH, ma in realtà non vuoi eseguire alcun comando remoto. Se tutto ciò che stai creando è un tunnel, includere questa opzione consente di risparmiare risorse.
• -T disabilita lallocazione pseudo-tty, che è appropriata perché “non lo fai cercando di creare una shell interattiva.

Ci sarà una verifica della password a meno che tu non abbia impostato le chiavi DSA o RSA per un accesso senza password.

Tieni presente che è FORTEMENTE ti consigliamo di utilizzare un account usa e getta (non il tuo login) che hai impostato solo per questo tunnel / cliente / server.

Ora, dalla tua shell su yourpublichost , stabilisci una connessione allhost protetto da firewall attraverso il tunnel:

ssh -p 22222 username@localhost 

Tu “ll ottenere una sfida chiave host, poiché probabilmente non hai mai raggiunto questo host prima. Quindi riceverai una verifica della password per laccount username (a meno che tu non abbia impostato le chiavi per laccesso senza password).

Se accederai regolarmente a questo host, puoi anche semplificare laccesso aggiungendo alcune righe al tuo file ~/.ssh/config:

host remotehostname User remoteusername Hostname localhost Port 22222 

Regola remotehostname e remoteusername per adattarlo. Il remoteusername il campo deve corrispondere al tuo nome utente sul server remoto, ma remotehostname può essere qualsiasi nome host che ti si addice, non è necessario che corrisponda a qualcosa di risolvibile.

Vedi anche:

• Esponi lendpoint inverso su un non-localhost IP
• Suggerimenti sullutilizzo di ControlMaster per mantenere il tuo tunnel

Commenti

• che dire di ssh -D. Spiega utilizzando lo stesso metodo.
• I proxy SOCKS non sono gli stessi dei tunnel. Se hai una domanda su come utilizzarli, chiedila .
• I ‘ Sto attraversando un periodo molto difficile nel seguire questa spiegazione a causa delluso sciolto dei termini: server, client, macchina locale, macchina remota, host, yourpublichost, localhost, remotehostname. Con tutti questi termini vaghi e indefiniti, si potrebbe presumere che qualcuno avrebbe bisogno di 8 computer per configurarlo. Lo dichiaro perché sotto tutti gli altri aspetti mi sembra unottima spiegazione. Riduci e definisci i termini.
• @ Rucent88, ‘ non sono sicuro di quale riduzione sarebbe possibile. Un client stabilisce una connessione a un server. Questa ‘ terminologia comune in tutto il mondo del networking. Le macchine locali e remote sembrano abbastanza evidenti. Se ‘ sei confuso su SSH o sulla terminologia unix generale dopo aver letto la documentazione, ‘ sono sicuro che ‘ non avrò problemi a trovare qui persone disposte a rispondere a qualsiasi domanda tu possa avere.
• @ghoti ‘ è davvero confuso, perché locale e le macchine remote sono relative. Quando mi siedo sul posto di lavoro il mio computer di casa è il telecomando, quando sono seduto a casa, il computer sul posto di lavoro è remoto. Server e client creano confusione anche quando si parla di tunneling. Ad esempio, se mi collego a casa dal lavoro con ssh -R. Mi collego al mio lavoro dal computer di casa collegandomi localhost. Quindi, dal punto di vista dei socket, il server è lo stesso computer di casa. Ma logicamente mi sono collegato al mio computer di lavoro. Questo ‘ è fonte di confusione.

Ho disegnato alcuni schizzi

La macchina in cui viene digitato il comando ssh tunnel si chiama »tuo host« .

Introduzione

1. local: -L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

   ssh -L sourcePort:forwardToHost:onPort connectToHost significa: connettiti con ssh a connectToHost e inoltra tutti i tentativi di connessione al locale sourcePort alla porta onPort sulla macchina denominata forwardToHost, che può essere raggiunto dalla connectToHost macchina.

2. remoto: -R Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side.

   ssh -R sourcePort:forwardToHost:onPort connectToHost significa: connettiti con ssh a connectToHost e inoltra tutti i tentativi di connessione al remoto sourcePort alla porta onPort sulla macchina denominata forwardToHost, che può essere raggiunta dalla macchina locale.

Opzioni aggiuntive

• -f dice a ssh di eseguire lo sfondo dopo lautenticazione, quindi non devi restare seduto a eseguire qualcosa sul server remoto per il tunnel rimanere in vita.
• -N dice che vuoi una connessione SSH, ma in realtà non vuoi eseguire alcun comando remoto. Se tutto ciò che stai creando è un tunnel, includere questa opzione consente di risparmiare risorse.
• -T disabilita lallocazione pseudo-tty, che è appropriata perché “non lo fai cercando di creare una shell interattiva.

Il tuo esempio

La terza immagine rappresenta questo tunnel. Ma il computer blu chiamato »tuo host« rappresenta il computer in cui qualcuno avvia il tunnel ssh, in questo caso la macchina protetta da firewall.

Quindi, chiedi a qualcuno di avviare una connessione tunnel ssh alla tua macchina. Il comando dovrebbe sostanzialmente assomigliare a

ssh -R 12345:localhost:22 YOURIP 

Ora il tunnel è aperto.Ora puoi connetterti tramite ssh alla macchina protetta da firewall attraverso il tunnel con il comando

ssh -p 12345 localhost 

che si connetterà al tuo localhost (la tua macchina) sulla porta 12345, ma la porta 12345 viene inoltrata attraverso il tunnel alla porta 22 dellhost locale del firewall computer (cioè lo stesso computer protetto da firewall).

Commenti

• @erik, come hai disegnato queste immagini?
• I ho utilizzato lo strumento di disegno vettoriale open source chiamato Inkscape e i miei mouse (beh, in realtà è una trackball: Marble FX di Logitech).
• @ghoti: per impostazione predefinita, il socket di ascolto sul server (nella mia immagine -R lhost remoto giallo) sarà associato solo all interfaccia di loopback. Questo può essere sovrascritto specificando un bind_address. Un bind_address vuoto o lindirizzo “*” indica che il socket remoto deve essere in ascolto su tutte le interfacce. – Quindi provalo: su un computer blu, avvia ssh -R 1234:localhost:8000 yellowcomputer. E anche sulla macchina blu avvia python -m SimpleHTTPServer (un semplice server web sulla porta 8000). Quindi in un browser web sulla macchina gialla apri lURL http://localhost:1234 e vedrai che funziona.
• @erik, ah, la parte confusa è perché i miei occhi sono male – ‘ non vedevo lo spazio prima di remotehost nei tuoi comandi. A un esame più attento, vedo che i tuoi diagrammi non ‘ in realtà indirizzano affatto il bind_address opzionale. Ci scusiamo per la confusione.
• @briankip Sì, ovviamente. Almeno se si desidera effettuare una connessione ssh al computer dietro il firewall (attraverso il tunnel o direttamente, se il firewall lo consente). Ad esempio: il comando ssh che scrivi sul computer protetto da firewall apre solo un tunnel, ma non si avvia o funziona come ssh-daemon / -server. La tua prossima domanda dovrebbe essere come avviare un sshd senza i privilegi di root (se questo è il tuo problema). 🙂

Il tunneling ssh funziona utilizzando la connessione ssh già stabilita per inviare traffico aggiuntivo.

Quando ti connetti a un server remoto, di solito hai solo 1 canale per la normale interazione dellutente (o 3 canali se consideri STDIN / STDOUT / STDERR separati). In qualsiasi momento, il processo ssh locale o remoto può aprire canali aggiuntivi sulla connessione esistente. Questi canali quindi inviano / ricevono il traffico del tunnel. Quando si invia o si riceve traffico, il processo ssh dice semplicemente “questo traffico è per il canale foobar”.

Funziona essenzialmente in questo modo:

1. Dite a ssh di iniziare ad ascoltare sulla porta XXXX e che il traffico ricevuto deve essere sottoposto a tunnel, quindi impostato su YYYY sulla porta ZZZZ.
2. LSSH locale inizia ad ascoltare sulla porta XXXX (generalmente su 127.0.0.1, ma può essere modificato).
3. Alcune applicazioni aprono una connessione alla porta XXXX sulla macchina locale.
4. Lssh locale apre un canale per lssh remoto e dice “qualsiasi traffico su questo canale va a YYYY: ZZZZ
5. Lssh remoto si connette a YYYY: ZZZZ e rimanda “OK, il canale è aperto”
6. Ora tutto il traffico inviato lungo la connessione alla porta XXXX sulla macchina locale viene inviato tramite proxy da ssh a YYYY: ZZZZ.

Questo processo è lo stesso sia per il tunneling diretto che per quello inverso (basta scambiare le parole “locale” e “remoto” in la procedura di cui sopra) Entrambe le parti possono avviare il tunnel non deve nemmeno esserlo al primo avvio di ssh. Puoi aprire i tunnel mentre ssh è già in esecuzione (vedi ESCAPE CHARACTERS, in particolare ~C).

Per il ruolo di -R, -f, -L e -N, dovresti davvero consultare la pagina man, ti dà la migliore spiegazione possibile. Ma “menzionerò -R e -L.
-R dice al telecomando ssh per ascoltare le connessioni e che lSSH locale dovrebbe connettersi alla destinazione reale. -L dice allSSH locale di ascoltare le connessioni e che lSSH remoto dovrebbe connettersi alla destinazione reale.

Nota, questa è una descrizione molto semplice, ma dovrebbe darti informazioni sufficienti per sapere cosa sta succedendo

Questo è spiegato nel manuale SSH, in particolare le differenze tra -L (local) e -R (remoto).

-L

-L [bind_address:]port:host:hostport

Specifica che la porta fornita sullhost locale (client) deve essere inoltrata allhost specificato e porta sul lato remoto .

Funziona allocando un socket per ascoltare la porta sul lato locale, facoltativamente associato a bind_address specificato.

Ogni volta che viene effettuata una connessione a questa porta, la connessione viene inoltrata tramite il canale protetto e viene stabilita una connessione a host porta hostport dalla macchina remota .

Il seguente esempio esegue il tunneling di una sessione IRC dal computer client 127.0.0.1 (localhost) utilizzando la porta 1234 al server remoto server.example.com:

$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 

^{Nota: lopzione -f sfondi ssh e il comando remoto sleep 10 è specificato per consentire una quantità di tempo per avviare il servizio che deve essere tunnelling.}

Esempio:

ssh `-N` -L 22000:localhost:11000 remote.server.com 

• -N Dopo esserti connesso, resta in attesa (non otterrai un prompt della shell)

  Non eseguire un comando remoto.

• -L 22000 La connessione avrà origine sulla porta 22000 del tuo L macchina ocale

• localhost:11000 – remote.server.com si assicurerà che laltra estremità del tunnel sia localhost, porta 11000

^{Fonte: Una guida illustrata, tutorial, istruzioni sul tunneling ssh .}

-R

-R [bind_address:]port:host:hostport

Specifica che la porta fornita sullhost remoto (server) deve essere inoltrata a g iven host e porta sul lato locale .

Funziona allocando un socket per ascoltare port su lato remoto e ogni volta che viene stabilita una connessione a questa porta, la connessione viene inoltrata sul canale protetto e una connessione viene effettuata in host porta hostport dalla macchina locale .

Esempio:

ssh -N -R 22000:localhost:11000 remote.server.com 

• -N Dopo esserti connesso, resta lì (non riceverai un prompt della shell)

  Non eseguire un comando remoto.

• -R 22000 La connessione avrà origine sulla porta 22000 del computer emote R (in questo caso, remote.server.com)

• il tuo computer locale personale si assicurerà che laltra estremità del tunnel sia localhost, porta 11000

^{Fonte: Una guida illustrata, tutorial, istruzioni sul tunneling ssh .}

Commenti

• lorecchio e la bocca rendono chiaro chi ‘ sta parlando e chi ‘ sta ascoltando!
• Adoro le tue illustrazioni!

Il collegamento alle interfacce di rete durante la creazione di tunnel SSH inversi è spiegato in questo post . Ecco un esempio con 4 computer che risiedono in due reti diverse: