Som jeg forstår dette, nægter firewalls (forudsat standardindstillinger) al indgående trafik, der ikke har nogen tidligere tilsvarende udgående trafik.
Baseret på Reversering af en ssh-forbindelse og SSH Tunneling Made Easy , kan reverse SSH-tunnel bruges til at få omkring irriterende firewallbegrænsninger.
Jeg vil gerne udføre shell-kommandoer på en ekstern maskine. Fjernmaskinen har sin egen firewall og er bag en ekstra firewall (router). Den har en IP-adresse som 192.168.1.126 (eller noget lignende). Jeg står ikke bag en firewall, og jeg kender fjernmaskinens IP-adresse set fra Internettet (ikke 192.168.1.126-adressen). Derudover kan jeg bede nogen om at udføre ssh (something) som rod på den eksterne maskine først.
Kunne nogen forklare mig trin for trin, hvordan omvendt SSH-tunneling fungerer for at komme rundt i firewalls (lokale og eksterne maskiner “firewalls og den ekstra firewall mellem dem)?
Hvad er kontaktenes rolle (-R, -f, -L, -N)?
Kommentarer
- Relateret (vejledning): Hvordan kan jeg konfigurere en omvendt SSH-forbindelse til den tilsluttende computer?
Svar
Jeg elsker at forklare denne slags ting gennem visualisering. 🙂
Tænk på dine SSH-forbindelser som rør. Store rør. Normalt strækker du dig gennem disse rør for at køre en skal på en fjerncomputer. Skallen kører i en virtuel terminal (tty). Men du kender allerede denne del.
Tænk på din tunnel som et rør i et rør. Du har stadig den store SSH-forbindelse, men indstillingen -L eller -R giver dig mulighed for at oprette et mindre rør inde i det.
Hvert rør har en begyndelse og en ende. Det store rør, din SSH-forbindelse, startet med din SSH-klient og ender på SSH-serveren, du har oprettet forbindelse til. Alle de mindre rør har de samme slutpunkter, bortset fra at rollen som “start” eller “slut” bestemmes af, om du brugte -L eller -R (henholdsvis) for at oprette dem.
(Du har ikke sagt, men jeg antager at den “eksterne” maskine, du har nævnt, den bag firewallen, kan få adgang til Internettet ved hjælp af Network Address Translation (NAT). Dette er lidt vigtigt, så ret denne antagelse, hvis den er falsk.)
Når du opretter en tunnel, angiver du en annonce kjole og port, som den vil svare på, og en adresse og port, som den vil blive leveret til. Indstillingen -L fortæller tunnelen at svare på den lokale side af tunnelen (værten, der kører din klient). Indstillingen -R fortæller tunnelen at svare på den eksterne side (SSH-serveren).
Så … For at kunne SSH fra Internettet til en maskine bag en firewall skal du bruge den pågældende maskine til at åbne en SSH-forbindelse til omverdenen og inkludere en -R tunnel, hvis” indgangspunkt “er den” fjerne “side af hans forbindelse.
Af de to modeller vist ovenfor vil du have den til højre.
Fra den firewallede vært:
ssh -f -N -T -R22222:localhost:22 yourpublichost.example.com Dette fortæller din klient at oprette en tunnel med en -R emote-post punkt. Alt, der er knyttet til port 22222 i den yderste ende af tunnelen, når faktisk “localhost port 22”, hvor “localhost” er set fra perspektivet til tunnelens udgangssted (dvs. din ssh-klient).
De andre muligheder er:
-
-ffortæller ssh til baggrunden selv, når den er godkendt, så du behøver ikke sidde og køre noget på fjernserver for at tunnelen skal forblive i live. -
-Nsiger, at du vil have en SSH-forbindelse, men at du faktisk ikke vil køre nogen fjernkommandoer. Hvis alt hvad du opretter er en tunnel, sparer du ressourcer ved at inkludere denne mulighed. -
-Tdeaktiverer pseudo-tty-tildeling, hvilket er passende, fordi du ikke er forsøger at oprette en interaktiv shell.
Der vil være en adgangskodeudfordring, medmindre du har konfigureret DSA- eller RSA-nøgler til et login uden adgangskode.
Bemærk, at det er STÆRKT anbefales, at du bruger en smidkonto (ikke dit eget login), som du opretter til netop denne tunnel / kunde / server.
Nu fra din shell på dinpublichost , opret forbindelse til den firewallede vært gennem tunnelen:
ssh -p 22222 username@localhost You “ll få en værtnøgleudfordring, da du sandsynligvis aldrig har ramt denne vært før. Derefter får du en adgangskodeudfordring til username -kontoen (medmindre du har opsat nøgler til login uden adgangskode).
Hvis du regelmæssigt får adgang til denne vært, kan du også forenkle adgangen ved at tilføje et par linjer til din ~/.ssh/config -fil:
host remotehostname User remoteusername Hostname localhost Port 22222 Juster remotehostname og remoteusername, så det passer. remoteusername -feltet skal matche dit brugernavn på fjernserveren, men remotehostname kan være ethvert værtsnavn, der passer dig, det behøver ikke at matche noget, der kan løses.
Se også:
- Udsæt det omvendte slutpunkt på et ikke-lokal vært IP
- Tips til brug af
ControlMasterfor at vedligeholde din tunnel
Kommentarer
- hvad med ssh -D. Forklar venligst ved hjælp af samme metode.
- SOCKS-proxyer er ikke det samme som tunneler. Hvis du har et spørgsmål om, hvordan du bruger dem, bedes du stille det .
- I ‘ Jeg har en meget vanskelig tid at følge denne forklaring på grund af den løse brug af udtryk: server, klient, lokal maskine, fjernmaskine, vært, dinpublichost, localhost, remotehostname. Med alle disse løse og udefinerede udtryk kunne det antages, at nogen ville have brug for så meget som 8 computere for at konfigurere dette. Jeg siger dette, fordi det i alle andre aspekter virker en meget god forklaring. Reducer og definer udtryk.
- @ Rucent88, jeg ‘ er ikke sikker på, hvilken reduktion der er mulig. En klient opretter en forbindelse til en server. Den ‘ s fælles terminologi over hele netværksverdenen. Lokale og eksterne maskiner virker ret indlysende. Hvis du ‘ er forvirret over SSH eller generel unix-terminologi efter at have læst dokumentationen, er jeg ‘ sikker på at du ‘ Jeg har ingen problemer med at finde folk her, der er meget villige til at besvare eventuelle spørgsmål, du måtte have.
- @ghoti Det ‘ er faktisk forvirrende, fordi det lokale og eksterne maskiner er relative. Når jeg sidder på arbejdspladsen, er min hjemmecomputer fjernbetjeningen, når jeg sidder hjemme, er arbejdspladscomputeren fjernbetjening. Server og klient er også forvirrende, når man taler om tunneling. For eksempel Hvis jeg opretter forbindelse til hjemmet fra arbejde med ssh -R. Jeg opretter forbindelse til mit arbejde fra hjemmecomputeren ved at forbinde localhost. Så fra sockets perspektiv er serveren selve hjemmecomputeren. Men logisk har jeg oprettet forbindelse til min arbejdscomputer. At ‘ er forvirrende.
Svar
Jeg har tegnet nogle skitser
Maskinen, hvor kommandoen ssh tunnel er skrevet, hedder »din vært« .
Introduktion
-
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 connectToHostbetyder: forbinde med ssh tilconnectToHost, og videresende alle forbindelsesforsøg til lokalesourcePorttil portonPortpå maskinen kaldetforwardToHost, som kan nås fraconnectToHost-maskinen. -
fjernbetjening:
-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 connectToHostbetyder: forbinde med ssh tilconnectToHost, og videresend alle forbindelsesforsøg til fjernbetjeningsourcePorttil portonPortpå maskinen kaldetforwardToHost, som kan nås fra din lokale maskine.
Yderligere indstillinger
-
-ffortæller ssh til baggrunden selv, når den er godkendt, så du behøver ikke sidde og køre noget på fjernserveren for at tunnelen skal forblive i live. -
-Nsiger, at du vil have en SSH-forbindelse, men at du faktisk ikke vil køre fjernkommandoer. Hvis alt hvad du opretter er en tunnel, sparer du ressourcer ved at inkludere denne mulighed. -
-Tdeaktiverer pseudo-tty-tildeling, hvilket er passende, fordi du ikke er forsøger at oprette en interaktiv skal.
Dit eksempel
Det tredje billede repræsenterer denne tunnel. Men den blå computer kaldet »din vært« repræsenterer den computer, hvor nogen starter ssh-tunnelen, i dette tilfælde den firewallede maskine.
Så spørg nogen om at starte en ssh-tunnelforbindelse til din maskine. Kommandoen skal stort set se ud
ssh -R 12345:localhost:22 YOURIP Nu åbnes tunnelen.Du kan nu oprette forbindelse via ssh til den firewallede maskine gennem tunnelen med kommandoen
ssh -p 12345 localhost som opretter forbindelse til din egen localhost (din maskine) på port 12345, men port 12345 videresendes gennem tunnelen til port 22 på localhost for firewalled computer (dvs. selve den firewallcomputer).
Kommentarer
- @erik, hvordan tegner du disse billeder?
- I brugte open source-vektortegningsværktøjet kaldet Inkscape og mine mus (ja det er faktisk en trackball: Marble FX fra Logitech).
- @ghoti: Som standard er lyttebøsningen på serveren (i mit -R-billede den gule remotehost) kun bundet til loopback interface . Dette kan tilsidesættes ved at angive en bind_adresse. En tom bind_address eller adressen * indikerer, at fjernbetjeningen skal lytte på alle grænseflader. – Så prøv det bare: Start
ssh -R 1234:localhost:8000 yellowcomputerpå en blå computer. Og også på den blå maskine startpython -m SimpleHTTPServer(en simpel webserver på port 8000). Åbn derefter URLenhttp://localhost:1234i en webbrowser på den gule maskine, og du vil se, at den fungerer. - @erik, ah, den forvirrende del er fordi mine øjne er dårligt – jeg så ikke ‘ ikke pladsen før
remotehosti dine kommandoer. Ved nærmere eftersyn ser jeg, at dine diagrammer ikke ‘ t rent faktisk adresserer den valgfri bind_adresse. Undskyld forvirringen. - @briankip Ja, selvfølgelig. I det mindste hvis du vil oprette en ssh-forbindelse til computeren bag firewallen (gennem tunnelen eller direkte, hvis firewallen tillader det). Dvs.: Den ssh-kommando, du skriver på den firewallede computer, åbner kun en tunnel, men starter ikke eller fungerer som en ssh-dæmon / server. Dit næste spørgsmål skal være, hvordan man starter en sshd uden root-rettigheder (hvis det er dit problem). 🙂
Svar
ssh-tunneling fungerer ved at bruge den allerede etablerede ssh-forbindelse til at sende yderligere trafik.
Når du opretter forbindelse til en ekstern server, har du normalt kun 1 kanal til den normale brugerinteraktion (eller 3 kanaler, hvis du betragter STDIN / STDOUT / STDERR separat). Den lokale eller eksterne ssh-proces kan til enhver tid åbne yderligere kanaler på den eksisterende forbindelse. Disse kanaler sender / modtager derefter tunneltrafikken. Når du sender eller modtager trafik, siger ssh-processen simpelthen “denne trafik er til kanalfobar”.
Det fungerer i det væsentlige sådan:
- Du beder ssh om at begynde at lytte på port XXXX, og at enhver modtaget trafik skal tunneleres og derefter indstilles til ÅÅÅÅ på port ZZZZ.
- Den lokale ssh begynder at lytte i port XXXX (generelt på
127.0.0.1, men kan ændres). - Nogle applikationer åbner en forbindelse til port XXXX på den lokale maskine.
- Den lokale ssh åbner en kanal til den eksterne ssh og siger “enhver trafik på denne kanal går til ÅÅÅÅ: ZZZZ
- Fjernbetjeningen ssh opretter forbindelse til ÅÅÅÅ: ZZZZ og sender “OK, kanalen er åben” tilbage
- Nu sendes al trafik langs forbindelsen til havnen XXXX på den lokale maskine proxies af ssh til YYYY: ZZZZ.
Denne proces er nøjagtig den samme for både fremadgående og omvendt tunneling (skift bare ordene “lokal” og “fjernbetjening” i ovenstående procedure). Begge sider kan starte tunnelen behøver ikke engang at være, når du starter ssh. Du kan åbne tunneler, mens ssh allerede kører (se ESCAPE CHARACTERS, specifikt ~C).
For rollen som -R, -f, -L og -N, skal du virkelig bare konsultere mandsiden, det giver dig den bedst mulige forklaring. Men jeg nævner -R og -L.
-R fortæller fjernbetjeningen ssh for at lytte efter forbindelser, og at den lokale ssh skal oprette forbindelse til den virkelige destination. -L beder den lokale ssh om at lytte efter forbindelser, og at fjerntliggende ssh skal oprette forbindelse til den rigtige destination.
Bemærk, dette er en meget rå beskrivelse, men det skal give dig nok information til at vide, hvad der foregår
Svar
Dette forklares i SSH manual, især forskellene mellem -L (local) og -R (fjernbetjening).
-L
-L [bind_address:]port:host:hostportAngiver, at den -porte på den lokale (klient) vært skal videresendes til den givne vært og port på den fjerne side .
Dette fungerer ved at tildele et stik til at lytte til port på den lokale side, eventuelt bundet til den angivne bind_address.
Når der oprettes forbindelse til denne port, forbindelsen videresendes over den sikre kanal, og der oprettes en forbindelse til
hostporthostportfra fjernmaskinen .
Følgende eksempel tunneler en IRC-session fra klientmaskine 127.0.0.1 (localhost) ved hjælp af port 1234 til ekstern server server.example.com:
$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 Bemærk: Muligheden -f baggrunde ssh og fjernkommandoen sleep 10 er angivet for at give et tidsrum til at starte den service, der skal tunneleres.
Eksempel:
ssh `-N` -L 22000:localhost:11000 remote.server.com -
-NNår du opretter forbindelse, skal du bare hænge der (du får ikke en shellprompt)Udfør ikke en fjernkommando.
-
-L 22000Forbindelsen stammer fra port 22000 af din personlige, L ocal maskine -
localhost:11000–remote.server.comsørger for, at den anden ende af tunnelen erlocalhost, port11000
Kilde: En illustreret guide, vejledning, vejledning om ssh-tunneling .
-R
-R [bind_address:]port:host:hostportAngiver, at den -porte på den eksterne (server) vært skal videresendes til g iven vært og port på den lokale side .
Dette fungerer ved at tildele et stik til at lytte til
portpå den fjerne side, og når der oprettes forbindelse til denne port, forbindelsen videresendes over den sikre kanal og en forbindelse oprettes tilhostporthostportfra den lokale maskine .
Eksempel:
ssh -N -R 22000:localhost:11000 remote.server.com -
-NNår du har oprettet forbindelse, skal du bare hænge der (du får ikke en shellprompt)Udfør ikke en fjernkommando.
-
-R22000 Forbindelsen stammer på port 22000 af R emote-computer (i dette tilfælde remote.server.com) -
din personlige, lokale computer sørger for, at den anden ende af tunnelen er
localhost, port11000
Kilde: En illustreret guide, vejledning, vejledning om ssh-tunneling .
Kommentarer
- øre og mund gør det krystalklart, hvem ‘ taler og hvem ‘ lytter!
- Jeg elsker dine illustrationer!
Svar
Binding til netværksgrænseflader under oprettelse af omvendte SSH-tunneller forklares i dette indlæg . Her er et eksempel med 4 computere, der findes i to forskellige netværk: 