Hvordan fungerer omvendt SSH-tunneling? (Norsk)

Som jeg forstår dette, nekter brannmurer (forutsatt standardinnstillinger) all innkommende trafikk som ikke har noen tidligere tilsvarende utgående trafikk.

Basert på Snu en ssh-forbindelse og SSH Tunneling Made Easy , kan reverse SSH-tunneling brukes til å få rundt irriterende brannmurrestriksjoner.

Jeg vil utføre skallkommandoer på en ekstern maskin. Den eksterne maskinen har sin egen brannmur og står bak en ekstra brannmur (ruter). Den har en IP-adresse som 192.168.1.126 (eller noe lignende). Jeg står ikke bak en brannmur og kjenner IP-adressen til den eksterne maskinen sett fra Internett (ikke 192.168.1.126-adressen). I tillegg kan jeg be noen utføre ssh (something) som rot på den eksterne maskinen først.

Kan noen forklare meg, trinn for trinn, hvordan omvendt SSH-tunneling fungerer for å komme rundt brannmurer (lokale og eksterne maskiner «brannmurer og den ekstra brannmuren mellom dem)?

Hva er rollen til bryterne (-R, -f, -L, -N)?

Kommentarer

Svar

Jeg elsker å forklare denne typen ting gjennom visualisering. 🙂

Tenk på SSH-forbindelsene dine som rør. Store rør. Normalt vil du strekke deg gjennom disse rørene for å kjøre et skall på en ekstern datamaskin. Skallet kjører i en virtuell terminal (tty). Men du kjenner denne delen allerede.

Tenk på tunnelen din som et rør i et rør. Du har fortsatt den store SSH-forbindelsen, men alternativet -L eller -R lar deg sette opp et mindre rør inne i det.

Hvert rør har en begynnelse og en slutt. Det store røret, SSH-tilkoblingen din, startet med SSH-klienten din og havner på SSH-serveren du koblet til. Alle de mindre rørene har de samme endepunktene, bortsett fra at rollen som «start» eller «slutt» bestemmes av om du brukte -L eller -R (henholdsvis) for å opprette dem.

(Du har ikke sagt, men jeg antar at den «eksterne» maskinen du har nevnt, den bak brannmuren, kan få tilgang til Internett ved hjelp av Network Address Translation (NAT). Dette er litt viktig, så rett denne antagelsen hvis den er falsk.)

Når du oppretter en tunnel, angir du en annonse kjole og port som den vil svare på, og en adresse og port som den skal leveres til. -L -alternativet forteller tunnelen å svare på den lokale siden av tunnelen (verten som driver klienten din). -R -alternativet forteller tunnelen å svare på den eksterne siden (SSH-serveren).

ssh-tunnelretninger

Så … For å kunne SSH fra Internett til en maskin bak en brannmur, trenger du den aktuelle maskinen for å åpne en SSH-forbindelse til omverdenen og inkludere en -R tunnel hvis» inngangspunkt «er den» eksterne «siden av forbindelsen hans.

Av de to modellene som vises ovenfor, vil du ha den til høyre.

Fra den brannmurede verten:

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

Dette forteller klienten din å opprette en tunnel med en -R emote-oppføring punkt. Alt som festes til port 22222 ytterst i tunnelen, når faktisk «localhost port 22», hvor «localhost» er fra perspektivet til tunnelens utgangspunkt (dvs. din ssh-klient).

De andre alternativene er:

  • -f forteller ssh til bakgrunnen selv etter at den er autentisert, så du trenger ikke sitte å kjøre noe på ekstern server for at tunnelen skal forbli i live.
  • -N sier at du vil ha en SSH-tilkobling, men at du faktisk ikke vil kjøre noen eksterne kommandoer. Hvis alt du oppretter er en tunnel, sparer du ressurser ved å inkludere dette alternativet.
  • -T deaktiverer pseudo-tty-tildeling, noe som er passende fordi du ikke er prøver å lage et interaktivt skall.

Det vil være en passordutfordring med mindre du har konfigurert DSA- eller RSA-nøkler for passordløs pålogging.

Merk at den er STERKT anbefalt at du bruker en kastekonto (ikke din egen innlogging) som du setter opp for nettopp denne tunnelen / kunden / serveren.

Nå, fra skallet ditt på yourpublichost , opprett en forbindelse til den brannmurede verten gjennom tunnelen:

ssh -p 22222 username@localhost 

You «ll få en vertnøkkelutfordring, ettersom du sannsynligvis aldri har truffet denne verten før. Deretter får du en passordutfordring for username -kontoen (med mindre du har konfigurert nøkler for passordløs pålogging).

Hvis du kommer til å få tilgang til denne verten regelmessig, kan du også forenkle tilgangen ved å legge til noen få linjer i ~/.ssh/config -filen:

host remotehostname User remoteusername Hostname localhost Port 22222 

Juster remotehostname og remoteusername for å passe. remoteusername -feltet må samsvare med brukernavnet ditt på den eksterne serveren, men remotehostname kan være hvilket som helst vertsnavn som passer deg, det trenger ikke å matche noe som kan løses.

Se også:

Kommentarer

  • hva med ssh -D. Forklar med samme metode.
  • SOCKS-fullmakter er ikke det samme som tunneler. Hvis du har spørsmål om hvordan du bruker dem, vennligst spør det .
  • I ‘ Jeg har det veldig vanskelig å følge denne forklaringen på grunn av løs bruk av vilkår: server, klient, lokal maskin, ekstern maskin, vert, dinpublichost, localhost, remotehostname. Med alle disse løse og udefinerte vilkårene, kan det antas at noen trenger så mye som 8 datamaskiner for å sette opp dette. Jeg uttaler dette fordi det i alle andre aspekter virker en veldig god forklaring. Vennligst reduser og definer termer.
  • @ Rucent88, jeg ‘ er ikke sikker på hvilken reduksjon som vil være mulig. En klient oppretter en forbindelse til en server. At ‘ er vanlig terminologi over hele verden av nettverk. Lokale og eksterne maskiner virker ganske selvinnlysende. Hvis du ‘ er forvirret om SSH eller generell unix-terminologi etter å ha lest dokumentasjonen, er jeg ‘ sikker på at du ‘ Jeg har ingen problemer med å finne folk her som er veldig villige til å svare på spørsmål du måtte ha.
  • @ghoti Det ‘ er virkelig forvirrende, fordi lokal og eksterne maskiner er relative. Når jeg sitter på arbeidsplassen er hjemmecomputeren min fjernkontroll, når jeg sitter hjemme, er datamaskinen på arbeidsplassen fjernkontroll. Server og klient er også forvirrende når vi snakker om tunneling. For eksempel Hvis jeg kobler meg hjem fra jobb med ssh -R. Jeg kobler meg til arbeidet mitt fra hjemme-datamaskinen ved å koble localhost. Så fra stikkontaktperspektiv er serveren selve hjemmedatamaskinen. Men logisk sett koblet jeg meg til arbeidsdatamaskinen min. At ‘ er forvirrende.

Svar

Jeg har tegnet noen skisser

Maskinen, der ssh-tunnelkommandoen er skrevet, heter »verten din .

ssh-tunnel fra lokal


ssh-tunnel fra fjernkontroll

Introduksjon

  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 betyr: koble med ssh til connectToHost, og videresend alle tilkoblingsforsøk til lokale sourcePort til port onPort på maskinen som heter forwardToHost, som kan nås fra connectToHost maskinen.

  2. fjernkontroll: -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 betyr: koble med ssh til connectToHost, og videresend alle tilkoblingsforsøk til fjernkontroll sourcePort til port onPort på maskinen som heter forwardToHost, som kan nås fra din lokale maskin.

Flere alternativer

  • -f forteller ssh til bakgrunnen selv etter at den er autentisert, så du trenger ikke sitte og kjøre noe på den eksterne serveren for at tunnelen skal forbli i live.
  • -N sier at du vil ha en SSH-tilkobling, men at du faktisk ikke vil kjøre noen eksterne kommandoer. Hvis alt du oppretter er en tunnel, sparer du ressurser ved å inkludere dette alternativet.
  • -T deaktiverer pseudo-tty-tildeling, noe som er passende fordi du ikke er prøver å lage et interaktivt skall.

Ditt eksempel

Det tredje bildet representerer denne tunnelen. Men den blå datamaskinen som heter »din vert« representerer datamaskinen der noen starter ssh-tunnelen, i dette tilfellet den brannmurte maskinen.

Be noen om å starte en ssh-tunnelforbindelse til maskinen din. Kommandoen skal i utgangspunktet se ut som

ssh -R 12345:localhost:22 YOURIP 

Nå er tunnelen åpnet.Du kan nå koble via ssh til den brannmurede maskinen gjennom tunnelen med kommandoen

ssh -p 12345 localhost 

som vil koble til din egen localhost (maskinen din) på port 12345, men port 12345 blir videresendt gjennom tunnelen til port 22 på den lokale brannmuren datamaskin (dvs. selve brannmuren).

Kommentarer

  • @erik, hvordan tegnet du disse bildene?
  • I brukte vektortegneverktøyet med åpen kildekode kalt Inkscape og musene mine (vel, det er faktisk en styrekule: Marble FX fra Logitech).
  • @ghoti: Som standard vil lyttekontakten på serveren (i mitt -R-bilde den gule fjernverten) bare være bundet til loopback grensesnittet . Dette kan overstyres ved å spesifisere en bind_adresse. En tom bind_adresse eller adressen ‘*’ indikerer at fjernkontakten skal lytte på alle grensesnitt. – Så bare prøv det: Start ssh -R 1234:localhost:8000 yellowcomputer på en blå datamaskin. Og start også på den blå maskinen python -m SimpleHTTPServer (en enkel webserver på port 8000). Åpne deretter URL-en http://localhost:1234 i en nettleser på den gule maskinen, så ser du at den fungerer.
  • @erik, ah, den forvirrende delen er fordi øynene mine er dårlig – jeg så ikke ‘ jeg så ikke plassen før remotehost i kommandoene dine. Ved nærmere ettersyn ser jeg at diagrammene dine ikke ‘ t faktisk adresserer den valgfrie bind_adressen i det hele tatt. Beklager forvirringen.
  • @briankip Ja, selvfølgelig. I det minste hvis du vil opprette en ssh-forbindelse til datamaskinen bak brannmuren (gjennom tunnelen eller direkte, hvis brannmuren tillater det). Det vil si: ssh-kommandoen du skriver på den brannmurte datamaskinen, åpner bare en tunnel, men starter ikke eller fungerer som en ssh-daemon / -server. Det neste spørsmålet ditt bør være, hvordan du starter en sshd uten root-rettigheter (hvis det er problemet ditt). 🙂

Svar

ssh-tunneling fungerer ved å bruke den allerede etablerte ssh-forbindelsen for å sende ekstra trafikk.

Når du kobler til en ekstern server, har du vanligvis bare 1 kanal for normal brukerinteraksjon (eller 3 kanaler hvis du anser STDIN / STDOUT / STDERR separat). Når som helst kan den lokale eller eksterne ssh-prosessen åpne flere kanaler på den eksisterende tilkoblingen. Disse kanalene sender / mottar deretter tunneltrafikken. Når du sender eller mottar trafikk, sier ssh-prosessen ganske enkelt «denne trafikken er for kanalfobar».

Den fungerer egentlig slik:

  1. Du ber ssh om å begynne å lytte på port XXXX og at all mottatt trafikk skal tunneleres, og deretter settes til ÅÅÅÅ på port ZZZZ.
  2. Den lokale ssh begynner å lytte på port XXXX (vanligvis på 127.0.0.1, men kan endres).
  3. Noen applikasjoner åpner en forbindelse til port XXXX på den lokale maskinen.
  4. Den lokale ssh åpner en kanal til den eksterne ssh og sier «all trafikk på denne kanalen går til ÅÅÅÅ: ZZZZ
  5. Fjernkontrollen ssh kobles til ÅÅÅÅ: ZZZZ og sender «OK, kanalen er åpen»
  6. Nå sendes trafikk langs forbindelsen til porten XXXX på den lokale maskinen er proxy av ssh til ÅÅÅÅ: ZZZZ.

Denne prosessen er nøyaktig den samme for både fremover og bakover tunneling (bare bytt ordene «lokal» og «ekstern» i fremgangsmåten ovenfor). Begge sider kan starte tunnelen trenger ikke engang å være når du starter ssh. Du kan åpne tunneler mens ssh allerede kjører (se ESCAPE CHARACTERS, spesielt ~C).

For rollen som -R, -f, -L og -N, burde du bare konsultere mannssiden, det gir deg best mulig forklaring. Men jeg nevner -R og -L.
-R forteller fjernkontrollen ssh for å lytte etter tilkoblinger, og at lokal ssh skal koble til den virkelige destinasjonen. -L ber den lokale ssh om å lytte etter tilkoblinger, og at ekstern ssh skal koble til den virkelige destinasjonen.

Merk, dette er en veldig grov beskrivelse, men den skal gi deg nok informasjon til å vite hva som skjer

Svar

Dette forklares i SSH-manualen, spesielt forskjellene mellom -L (lokal) og -R (ekstern).


-L

-L [bind_address:]port:host:hostport

Spesifiserer at gitt port på den lokale (klient) verten skal videresendes til den angitte verten og port på den eksterne siden .

Dette fungerer ved å tildele en stikkontakt for å lytte til port på den lokale siden, eventuelt bundet til den angitte bind_adressen.

Hver gang det blir koblet til denne porten, forbindelsen videresendes over den sikre kanalen, og det opprettes en forbindelse til host port hostport fra den eksterne maskinen .

Følgende eksempel tunneler en IRC-økt fra klientmaskinen 127.0.0.1 (localhost) ved hjelp av port 1234 til ekstern server server.example.com:

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

Merk: -f alternativet bakgrunner ssh og fjernkommandoen sleep 10 er spesifisert for å tillate en tid å starte tjenesten som skal tunneleres.

Eksempel:

ssh `-N` -L 22000:localhost:11000 remote.server.com 
  • -N Når du har koblet til, er det bare å henge der (du får ikke en shell-melding)

    Ikke utfør en fjernkommando.

  • -L 22000 Tilkoblingen kommer fra port 22000 av din personlige, L ocal machine

  • localhost:11000remote.server.com vil sørge for at den andre enden av tunnelen er localhost, port 11000

ssh -N -L 22000: 192.168.1.2: 11000 remote.server.com

Kilde: En illustrert guide, veiledning, veiledning, om ssh-tunneling .


-R

-R [bind_address:]port:host:hostport

Spesifiserer at gitt port på den eksterne (server) verten skal videresendes til g iven vert og port på den lokale siden .

Dette fungerer ved å tildele en stikkontakt for å lytte til port på den eksterne siden, og når en forbindelse blir opprettet til denne porten, blir forbindelsen videresendt over den sikre kanalen, og en tilkobling er laget til host port hostport fra den lokale maskinen .

Eksempel:

ssh -N -R 22000:localhost:11000 remote.server.com 
  • -N Når du har koblet til, er det bare å henge der (du får ikke en shell-melding)

    Ikke kjør en ekstern kommando.

  • -R 22000 Tilkoblingen vil oppstå på port 22000 av R emote datamaskin (i dette tilfellet remote.server.com)

  • din personlige, lokale datamaskin vil sørge for at den andre enden av tunnelen er localhost, port 11000

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

Kilde: En illustrert guide, veiledning, veiledning, om ssh-tunneling .

Kommentarer

  • øret og munnen gjør det krystallklart hvem ‘ snakker og som ‘ lytter!
  • Jeg elsker illustrasjonene dine!

Svar

Binding til nettverksgrensesnitt mens du oppretter omvendte SSH-tunneler er forklart i dette innlegget . Her er et eksempel med fire datamaskiner som ligger i to forskjellige nettverk:

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *