Hur fungerar omvänd SSH-tunnling?

Jag har ritat några skisser

Maskinen, där ssh-tunnelkommandot skrivs, heter »din värd« .

Introduktion

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 betyder: anslut med ssh till connectToHost och vidarebefordra alla anslutningsförsök till lokalt sourcePort till port onPort på maskinen som heter forwardToHost, som kan nås från connectToHost -maskinen.

2. fjärrkontroll: -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 betyder: anslut med ssh till connectToHost och vidarebefordra alla anslutningsförsök till fjärrkontroll sourcePort till port onPort på maskinen som heter forwardToHost, som kan nås från din lokala maskin.

Ytterligare alternativ

• -f säger till ssh till bakgrunden efter att den har autentiserats, så du behöver inte sitta och köra något på fjärrservern för att tunneln ska förbli vid liv.
• -N säger att du vill ha en SSH-anslutning, men du vill faktiskt inte köra några fjärrkommandon. Om allt du skapar är en tunnel sparar du resurser genom att inkludera detta alternativ.
• -T inaktiverar pseudo-tty-allokering, vilket är lämpligt eftersom du inte är försöker skapa ett interaktivt skal.

Ditt exempel

Den tredje bilden representerar denna tunnel. Men den blå datorn som heter »din värd« representerar datorn där någon startar ssh-tunneln, i det här fallet den brandväggade maskinen.

Så be någon att starta en ssh-tunnelanslutning till din maskin. Kommandot ska i princip se ut

ssh -R 12345:localhost:22 YOURIP 

Nu öppnas tunneln.Nu kan du ansluta via ssh till den brandväggade maskinen genom tunneln med kommandot

ssh -p 12345 localhost 

som kommer att ansluta till din egen localhost (din maskin) på port 12345, men port 12345 vidarebefordras genom tunneln till port 22 på localhost för den brandväggade dator (dvs. den brandväggade datorn i sig).

Kommentarer

• @erik, hur ritade du dessa bilder?
• I använde vektorritningsverktyget med öppen källkod som heter Inkscape och mina möss (ja det är faktiskt en trackball: Marble FX från Logitech).
• @ghoti: Som standard kommer lyssningsuttaget på servern (i min -R-bild den gula fjärrvärden) endast att vara bunden till loopback gränssnittet . Detta kan åsidosättas genom att ange en bind_adress. En tom bindeadress eller adressen * indikerar att fjärrkontakten ska lyssna på alla gränssnitt. – Så prova bara: Starta ssh -R 1234:localhost:8000 yellowcomputer på en blå dator. Och även på den blå maskinen startar python -m SimpleHTTPServer (en enkel webserver på port 8000). Öppna sedan webbadressen i en webbläsare på den gula maskinen http://localhost:1234 så ser du att den fungerar.
• @erik, ah, den förvirrande delen beror på att mina ögon är dåligt – jag såg ’ jag såg inte utrymmet före remotehost i dina kommandon. Vid en närmare granskning ser jag att dina diagram inte ’ faktiskt inte adresserar den valfria bindningsadressen alls. Ledsen för förvirringen.
• @briankip Ja, naturligtvis. Åtminstone om du vill skapa en ssh-anslutning till datorn bakom brandväggen (genom tunneln eller direkt, om brandväggen tillåter det). Det vill säga: ssh-kommandot du skriver på den brandväggade datorn öppnar bara en tunnel, men startar inte eller fungerar som en ssh-daemon / -server. Din nästa fråga bör vara, hur man startar en sshd utan root-behörigheter (om det är ditt problem). 🙂

ssh-tunnling fungerar med den redan etablerade ssh-anslutningen för att skicka ytterligare trafik.

När du ansluter till en fjärrserver har du vanligtvis bara en kanal för normal användarinteraktion (eller 3 kanaler om du anser att STDIN / STDOUT / STDERR är separat). När som helst kan den lokala eller fjärrstyrda ssh-processen öppna ytterligare kanaler på den befintliga anslutningen. Dessa kanaler skickar / tar sedan emot tunneltrafiken. När du skickar eller tar emot trafik säger ssh-processen helt enkelt ”den här trafiken är för kanalfobar”.

Det fungerar i princip så här:

1. Du säger till ssh att börja lyssna på port XXXX och att all mottagen trafik ska tunneleras och sedan ställas till YYYY på port ZZZZ.
2. Den lokala ssh börjar lyssna på port XXXX (vanligtvis på 127.0.0.1, men kan ändras).
3. Vissa program öppnar en anslutning till port XXXX på den lokala maskinen.
4. Den lokala ssh öppnar en kanal till fjärr-ssh och säger ”all trafik på den här kanalen går till ÅÅÅÅ: ZZZZ
5. Fjärrkontrollen ssh ansluter till ÅÅÅÅ: ZZZZ och skickar tillbaka ”OK, kanalen är öppen”
6. Nu skickas all trafik längs anslutningen till port XXXX på den lokala maskinen proxies av ssh till YYYY: ZZZZ.

Denna process är exakt densamma för både framåt och bakåt tunnling (byt bara orden ”lokal” och ”fjärr” i ovanstående procedur). Båda sidor kan starta tunneln behöver inte ens vara när du börjar ssh. Du kan öppna tunnlar medan ssh redan körs (se ESCAPE CHARACTERS, specifikt ~C).

För rollen som -R, -f, -L och -N, du borde verkligen konsultera mansidan, det ger dig bästa möjliga förklaring. Men jag nämner -R och -L.
-R berättar fjärrkontrollen ssh för att lyssna efter anslutningar och att den lokala ssh ska ansluta till den verkliga destinationen. -L ber den lokala ssh att lyssna efter anslutningar, och att fjärr-ssh ska ansluta till den verkliga destinationen.

Obs, detta är en väldigt grov beskrivning, men den borde ge dig tillräckligt med information för att veta vad som händer

Detta förklaras i SSH-manualen, särskilt skillnaderna mellan -L (lokal) och -R (fjärrkontroll).

-L

-L [bind_address:]port:host:hostport

Anger att -porten på den lokala (klient) värden ska vidarebefordras till den givna värden och port på fjärrsidan .

Detta fungerar genom att tilldela ett uttag för att lyssna på port på den lokala sidan, eventuellt bunden till den angivna bindningsadressen.

När en anslutning görs till den här porten, anslutningen vidarebefordras över den säkra kanalen och en anslutning görs till host port hostport från fjärrmaskinen .

Följande exempel tunnlar en IRC-session från klientdator 127.0.0.1 (localhost) med port 1234 till fjärrserver server.example.com:

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

^{Obs! Alternativet -f bakgrunder ssh och fjärrkommandot sleep 10 är specificerat för att tillåta en tid att starta tjänsten som ska tunnlas.}

Exempel:

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

• -N När du har anslutit är det bara att hänga där (du får inte en shell-prompt)

  Kör inte ett fjärrkommando.

• -L 22000 Anslutningen kommer från port 22000 i din personliga, L ocal machine

• localhost:11000 – remote.server.com ser till att tunnelns andra ände är localhost, port 11000

^{Källa: En illustrerad guide, handledning, hur man gör, om ssh-tunnling .}

-R

-R [bind_address:]port:host:hostport

Anger att den -porten på fjärrvärden (server) som ska vidarebefordras till g iven värd och port på den lokala sidan .

Detta fungerar genom att tilldela ett uttag för att lyssna på port på fjärrsidan, och när en anslutning görs till den här porten, vidarebefordras anslutningen över den säkra kanalen och en anslutning görs till host port hostport från den lokala maskinen .

Exempel:

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

• -N När du ansluter är det bara att hänga där (du får inte en shell-prompt)

  Kör inte ett fjärrkommando.

• -R 22000 Anslutningen kommer på port 22000 på R emote-dator (i det här fallet remote.server.com)

• din personliga, lokala dator ser till att den andra änden av tunneln är localhost, port 11000

^{Källa: En illustrerad guide, handledning, hur man gör, om ssh-tunnling .}

Kommentarer

• örat och munnen gör det kristallklart vem ’ talar och som ’ lyssnar!
• Jag älskar dina illustrationer!

Bindning till nätverksgränssnitt vid upprättande av omvända SSH-tunnlar förklaras i detta inlägg . Här är ett exempel med fyra datorer som finns i två olika nätverk: