Hoe werkt reverse SSH-tunneling?

Ik leg dit soort dingen graag uit door middel van visualisatie. 🙂

Beschouw uw SSH-verbindingen als buizen. Grote buizen. Normaal gesproken reik je door deze buizen om een shell op een externe computer te laten draaien. De shell draait in een virtuele terminal (tty). Maar je kent dit deel al.

Zie je tunnel als een buis binnen een buis. Je hebt nog steeds de grote SSH-verbinding, maar met de optie -L of -R kun je een kleinere buis erin opzetten.

Elke buis heeft een begin en een einde. De grote buis, je SSH-verbinding, gestart met je SSH-client en eindigt op de SSH-server waarmee je verbinding hebt gemaakt. Alle kleinere buizen hebben dezelfde eindpunten, behalve dat de rol van “start” of “end” wordt bepaald door of je -L of -R (respectievelijk) om ze te maken.

(Je hebt het niet gezegd, maar ik ga er vanuit dat dat de “externe” machine die je hebt genoemd, die achter de firewall, toegang heeft tot internet met behulp van Network Address Translation (NAT). Dit is nogal belangrijk, dus corrigeer deze aanname als deze niet waar is.)

Wanneer u een tunnel maakt, specificeert u een advertentie jurk en haven waarop het zal antwoorden, en een adres en haven waar het zal worden afgeleverd. De -L optie vertelt de tunnel om te antwoorden aan de lokale kant van de tunnel (de host die je client draait). De -R optie vertelt de tunnel om te antwoorden op de externe kant (de SSH-server).

Dus … Om SSH van internet naar een machine achter een firewall te kunnen sturen, heb je de betreffende machine nodig om een SSH-verbinding met de buitenwereld te openen en een -R tunnel waarvan het” toegangspunt “de” externe “kant van zijn verbinding is.

Van de twee hierboven getoonde modellen wil je degene aan de rechterkant.

Van de host met firewall:

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

Dit vertelt je cliënt om een tunnel tot stand te brengen met een -R emote-item punt. Alles wat aan poort 22222 aan het uiteinde van de tunnel wordt gekoppeld, zal daadwerkelijk “localhost poort 22” bereiken, waar “localhost” is vanuit het perspectief van het uitgangspunt van de tunnel (dwz uw ssh-client).

De andere opties zijn:

• -f vertelt ssh om zichzelf op de achtergrond te zetten nadat het is geverifieerd, dus je hoeft niet te blijven zitten om iets op de externe server zodat de tunnel in leven blijft.
• -N zegt dat je een SSH-verbinding wilt, maar eigenlijk geen externe commandos wilt uitvoeren. Als alles wat je maakt een tunnel is, dan worden door het opnemen van deze optie bronnen opgeslagen.
• -T schakelt pseudo-tty-toewijzing uit, wat passend is omdat je dat niet doet. proberen een interactieve shell te maken.

Er zal een wachtwoorduitdaging zijn, tenzij je DSA- of RSA-sleutels hebt ingesteld voor een wachtwoordloze login.

Merk op dat het STERK is aanbevolen dat je een wegwerpaccount gebruikt (niet je eigen login) die je hebt ingesteld voor alleen deze tunnel / klant / server.

Nu, vanuit je shell op yourpublichost , breng een verbinding tot stand met de firewall-host via de tunnel:

ssh -p 22222 username@localhost 

U zult krijg een hostsleuteluitdaging, aangezien je deze host waarschijnlijk nog nooit eerder hebt geraakt. Dan krijg je een wachtwoordchallenge voor het username account (tenzij je sleutels hebt ingesteld voor inloggen zonder wachtwoord).

Als u “deze host regelmatig gaat bezoeken, kunt u de toegang ook vereenvoudigen door een paar regels toe te voegen aan uw ~/.ssh/config -bestand:

host remotehostname User remoteusername Hostname localhost Port 22222 

Pas remotehostname en remoteusername aan. De remoteusername veld moet overeenkomen met je gebruikersnaam op de server op afstand, maar remotehostname kan elke hostnaam zijn die bij je past, het hoeft niet overeen te komen met iets dat kan worden opgelost.

Zie ook:

• Stel het omgekeerde eindpunt bloot op een non-localhost IP
• Tips voor het gebruik van ControlMaster om uw tunnel te onderhouden

Reacties

• hoe zit het met ssh -D. Leg uit met dezelfde methode.
• SOCKS-proxys zijn niet hetzelfde als tunnels. Als u een vraag heeft over het gebruik ervan, stel deze dan .
• I ‘ Ik heb het erg moeilijk om deze uitleg te volgen vanwege het losse gebruik van termen: server, client, lokale machine, externe machine, host, yourpublichost, localhost, remotehostname. Met al deze losse en ongedefinieerde termen kan worden aangenomen dat iemand maar liefst 8 computers nodig heeft om dit op te zetten. Ik verklaar dit omdat het in alle andere aspecten een heel goede verklaring lijkt. Verminder en definieer termen.
• @ Rucent88, ik ‘ m niet zeker welke reductie mogelijk zou zijn. Een client brengt een verbinding tot stand met een server. Die ‘ s algemene terminologie over de hele netwerkwereld. Lokale en externe machines lijken vrij vanzelfsprekend. Als u ‘ in de war bent over SSH of de algemene Unix-terminologie na het lezen van de documentatie, ‘ weet ik zeker dat u ‘ Ik heb hier geen moeite om mensen te vinden die bereid zijn al je vragen te beantwoorden.
• @ghoti Het ‘ is inderdaad verwarrend, omdat lokale en afgelegen machines zijn relatief. Als ik op de werkplek zit, is mijn homecomputer de afstandsbediening, als ik thuis zit, is de werkplekcomputer de afstandsbediening. Server en client zijn ook verwarrend als het over tunneling gaat. Bijvoorbeeld als ik vanuit mijn werk verbinding maak met thuis met ssh -R. Ik maak verbinding met mijn werk vanaf de thuiscomputer door localhost aan te sluiten. Dus vanuit sockets-perspectief is de server zelf een homecomputer. Maar logischerwijs maakte ik verbinding met mijn werkcomputer. Dat ‘ is verwarrend.

Ik heb getekend enkele schetsen

De machine, waar het ssh-tunnelcommando wordt getypt, wordt »uw host« genoemd.

Inleiding

1. lokaal: -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 betekent: maak verbinding met ssh naar connectToHost, en stuur alle verbindingspogingen door naar de lokale sourcePort naar port onPort op de machine met de naam forwardToHost, die kan worden bereikt vanaf de connectToHost machine.

2. remote: -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 betekent: verbind met ssh naar connectToHost, en stuur alle verbindingspogingen door naar de externe sourcePort om op de machine met de naam forwardToHost, die kan worden bereikt vanaf uw lokale machine.

Extra opties

• -f vertelt ssh om zichzelf op de achtergrond te zetten nadat het is geverifieerd, dus je hoeft niet te blijven zitten draaien op de externe server om de tunnel te laten in leven blijven.
• -N zegt dat je een SSH-verbinding wilt, maar dat je eigenlijk geen externe commandos wilt uitvoeren. Als alles wat je maakt een tunnel is, dan worden door het opnemen van deze optie bronnen opgeslagen.
• -T schakelt pseudo-tty-toewijzing uit, wat passend is omdat je dat niet doet. proberen een interactieve shell te maken.

Jouw voorbeeld

De derde afbeelding stelt deze tunnel voor. Maar de blauwe computer met de naam »uw host« vertegenwoordigt de computer waarop iemand de ssh-tunnel start, in dit geval de firewall-machine.

Dus, vraag iemand om een ssh-tunnelverbinding met uw machine te starten. Het commando zou er in wezen als volgt uit moeten zien

ssh -R 12345:localhost:22 YOURIP 

Nu is de tunnel geopend.U kunt nu via ssh verbinding maken met de firewall-machine via de tunnel met het commando

ssh -p 12345 localhost 

dat zal verbinden met uw eigen localhost (jouw machine) op poort 12345, maar poort 12345 wordt doorgestuurd door de tunnel naar poort 22 van de localhost van de firewall computer (dwz de computer met firewall zelf).

Reacties

• @erik, Hoe heb je deze afbeeldingen getekend?
• I gebruikte het open source vectortekenprogramma Inkscape en mijn muizen (nou ja, eigenlijk is het een trackball: Marble FX van Logitech).
• @ghoti: Standaard is de luisterende socket op de server (in mijn -R afbeelding de gele remotehost) alleen gebonden aan de loopback interface . Dit kan worden opgeheven door een bind_adres op te geven. Een leeg bind_adres of het adres ‘*’ geeft aan dat de externe socket op alle interfaces moet luisteren. – Dus probeer het gewoon: start op een blauwe computer ssh -R 1234:localhost:8000 yellowcomputer. En ook op de blauwe machine start python -m SimpleHTTPServer (een simpele webserver op poort 8000). Open vervolgens in een webbrowser op de gele machine de URL http://localhost:1234 en je zult zien dat het werkt.
• @erik, ah, het verwarrende is dat mijn ogen slecht – ik ‘ kon de spatie vóór remotehost in uw opdrachten niet zien. Bij nader inzien zie ik dat uw diagrammen ‘ überhaupt niet het optionele bind_address adresseren. Sorry voor de verwarring.
• @briankip Ja, natuurlijk. Tenminste als je een ssh-verbinding wilt maken met de computer achter de firewall (via de tunnel of direct, als de firewall dat toelaat). D.w.z .: Het ssh-commando dat je schrijft op de computer met firewall opent alleen een tunnel, maar start niet of werkt niet als een ssh-daemon / -server. Uw volgende vraag zou moeten zijn: hoe u een sshd start zonder rootrechten (als dat uw probleem is). 🙂

ssh-tunneling werkt door de reeds tot stand gebrachte ssh-verbinding te gebruiken voor het verzenden van extra verkeer.

Als je verbinding maakt met een externe server, heb je meestal maar 1 kanaal voor de normale gebruikersinteractie (of 3 kanalen als je STDIN / STDOUT / STDERR apart beschouwt). Het lokale of externe SSH-proces kan op elk moment extra kanalen openen op de bestaande verbinding. Deze kanalen verzenden / ontvangen vervolgens het tunnelverkeer. Bij het verzenden of ontvangen van verkeer, zegt het ssh-proces simpelweg “dit verkeer is voor kanaal foobar”.

Het werkt in wezen als volgt:

1. Je vertelt ssh om te beginnen met luisteren op poort XXXX en dat al het ontvangen verkeer moet worden getunneld, en vervolgens moet worden ingesteld op YYYY op poort ZZZZ.
2. De lokale ssh begint te luisteren op poort XXXX (meestal op 127.0.0.1, maar kan worden gewijzigd).
3. Sommige applicaties openen een verbinding met poort XXXX op de lokale computer.
4. De lokale ssh opent een kanaal naar de externe ssh en zegt “elk verkeer op dit kanaal gaat naar YYYY: ZZZZ
5. De remote ssh maakt verbinding met YYYY: ZZZZ en stuurt het “OK, kanaal is open” terug.
6. Nu wordt al het verkeer via de verbinding naar de poort gestuurd XXXX op de lokale machine wordt door ssh als proxy aangeduid met YYYY: ZZZZ.

Dit proces is exact hetzelfde voor zowel voorwaarts als achterwaarts tunnelen (verwissel gewoon de woorden lokaal en op afstand in de bovenstaande procedure). Beide zijden kunnen de tunnel starten hoeft niet eens te zijn wanneer je ssh voor het eerst start. U kunt tunnels openen terwijl ssh al actief is (zie ESCAPE CHARACTERS, in het bijzonder ~C).

Voor de rol van -R, -f, -L, en -N, je zou eigenlijk gewoon de man-pagina moeten raadplegen, het geeft je de best mogelijke uitleg. Maar ik “zal -R en -L noemen.
-R vertelt de externe ssh om naar verbindingen te luisteren, en dat de lokale ssh verbinding moet maken met de echte bestemming. -L vertelt de lokale ssh om naar verbindingen te luisteren, en die externe ssh moet verbinding maken met de echte bestemming.

Let op, dit is een erg grove beschrijving, maar het zou je genoeg informatie moeten geven om te weten wat er aan de hand is

Dit wordt uitgelegd in de SSH-handleiding, vooral de verschillen tussen -L (lokaal) en -R (op afstand).

-L

-L [bind_address:]port:host:hostport

Specificeert dat de opgegeven poort op de lokale (client) host moet worden doorgestuurd naar de opgegeven host en poort aan de externe kant .

Dit werkt door een socket toe te wijzen om naar de poort aan de lokale kant te luisteren, optioneel gebonden aan het opgegeven bind_adres.

Telkens wanneer een verbinding met deze poort wordt gemaakt, de verbinding wordt doorgestuurd via het beveiligde kanaal en er wordt een verbinding gemaakt naar host poort hostport van de externe machine .

Het volgende voorbeeld tunnelt een IRC-sessie vanaf de clientcomputer 127.0.0.1 (localhost) met behulp van poort 1234 naar de externe server server.example.com:

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

^{Opmerking: de -f optie achtergronden ssh en het externe commando sleep 10 is gespecificeerd om een bepaalde tijd te geven om de service te starten die moet worden getunneld.}

Voorbeeld:

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

• -N Nadat je verbinding hebt gemaakt, blijf daar gewoon hangen (je krijgt geen shell-prompt)

  Voer geen commando op afstand uit.

• -L 22000 De verbinding zal ontstaan op poort 22000 van uw persoonlijke, L ocal machine

• localhost:11000 – remote.server.com zorgt ervoor dat het andere uiteinde van de tunnel localhost, poort 11000

^{Bron: Een geïllustreerde gids, tutorial, how-to, over ssh-tunneling .}

-R

-R [bind_address:]port:host:hostport

Specificeert dat de opgegeven poort op de externe (server) host moet worden doorgestuurd naar de g iven host en poort aan de lokale kant .

Dit werkt door een socket toe te wijzen om naar port te luisteren de externe kant, en wanneer er verbinding wordt gemaakt met deze poort, wordt de verbinding doorgestuurd via het beveiligde kanaal, en een verbinding is naar host poort hostport gemaakt vanaf de lokale computer .

Voorbeeld:

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

• -N Nadat je verbinding hebt gemaakt, blijf daar gewoon hangen (je krijgt geen shell-prompt)

  Voer geen opdracht op afstand uit.

• -R 22000 De verbinding komt tot stand op poort 22000 van de R emote computer (in dit geval remote.server.com)

• uw persoonlijke, lokale computer zal ervoor zorgen dat het andere uiteinde van de tunnel localhost, poort 11000

^{Bron: Een geïllustreerde gids, tutorial, how-to, over ssh-tunneling .}

Opmerkingen

• het oor en de mond maken glashelder wie ‘ s praat en wie ‘ luistert!
• Ik hou van je illustraties!

Het verbinden met netwerkinterfaces tijdens het opzetten van reverse SSH-tunnels wordt uitgelegd in deze post . Hier is een voorbeeld met 4 computers die zich in twee verschillende netwerken bevinden: