Jak działa odwrotne tunelowanie SSH?

Uwielbiam wyjaśniać takie rzeczy za pomocą wizualizacji. 🙂

Pomyśl o połączeniach SSH jak o rurach. Duże rurki. Zwykle sięgniesz przez te rury, aby uruchomić powłokę na zdalnym komputerze. Powłoka działa w wirtualnym terminalu (tty). Ale znasz już tę część.

Pomyśl o swoim tunelu jak o rurze w rurze. Nadal masz duże połączenie SSH, ale opcja -L lub -R pozwala ustawić w niej mniejszą rurkę.

Każda rura ma początek i koniec. Duża rura, Twoje połączenie SSH, rozpoczęte od klienta SSH i kończące się na serwerze SSH, z którym się łączyłeś. Wszystkie mniejsze rury mają te same punkty końcowe, z wyjątkiem tego, że rola „start” lub „end” jest określana przez to, czy użyłeś -L lub -R (odpowiednio), aby je utworzyć.

(Nie powiedziałeś, ale zamierzam założyć że „zdalna” maszyna, o której wspomniałeś, ta znajdująca się za zaporą, może uzyskać dostęp do Internetu za pomocą translacji adresów sieciowych (NAT). Jest to dość ważne, więc popraw to założenie, jeśli jest fałszywe.)

Tworząc tunel, określasz reklamę sukienkę i port, na który odpowie, a także adres i port, na który zostanie dostarczona. Opcja -L mówi tunelowi, aby odpowiadał po lokalnej stronie tunelu (host, na którym działa twój klient). Opcja -R informuje tunel, aby odebrał odpowiedź po stronie zdalnej (serwer SSH).

A więc … Aby móc SSH z Internetu do komputera znajdującego się za zaporą ogniową, musisz na tej maszynie otworzyć połączenie SSH ze światem zewnętrznym i dołączyć -R tunel, którego„ punktem wejścia ”jest„ zdalna ”strona jego połączenia.

Spośród dwóch pokazanych powyżej modeli, ten powinien znajdować się po prawej stronie.

Z hosta z zaporą ogniową:

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

To mówi klientowi, aby ustanowił tunel z -R wpisem emotikonów punkt. Wszystko, co jest dołączone do portu 22222 na drugim końcu tunelu, w rzeczywistości dotrze do „localhost port 22”, gdzie „localhost” jest z punktu widzenia punktu wyjścia tunelu (tj. Twojego klienta ssh).

Inne opcje to:

• -f mówi ssh do samego tła po uwierzytelnieniu, więc nie musisz siedzieć i uruchamiać coś na zdalny serwer, aby tunel pozostał aktywny.
• -N mówi, że chcesz mieć połączenie SSH, ale tak naprawdę nie chcesz uruchamiać żadnych zdalnych poleceń. Jeśli wszystko, co tworzysz, to tunel, włączenie tej opcji oszczędza zasoby.
• -T wyłącza alokację pseudo-tty, co jest odpowiednie, ponieważ nie próba utworzenia interaktywnej powłoki.

Będzie wyzwanie związane z hasłem, chyba że skonfigurujesz klucze DSA lub RSA dla logowania bez hasła.

Zauważ, że jest to MOCNE zalecane, abyś użył konta jednorazowego użytku (nie własnego loginu), które skonfigurowałeś tylko dla tego tunelu / klienta / serwera.

Teraz z Twojej powłoki na yourpublichost , nawiąż połączenie z hostem chronionym firewallem przez tunel:

ssh -p 22222 username@localhost 

You „ll zdobądź kluczowy wyzwanie dla hosta, ponieważ prawdopodobnie nigdy wcześniej nie trafiłeś na tego hosta. Następnie „otrzymasz wyzwanie dotyczące hasła dla konta username (chyba że skonfigurowałeś klucze do logowania bez hasła).

Jeśli chcesz regularnie uzyskiwać dostęp do tego hosta, możesz również uprościć dostęp, dodając kilka wierszy do swojego pliku ~/.ssh/config:

host remotehostname User remoteusername Hostname localhost Port 22222 

Dopasuj remotehostname i remoteusername do swoich potrzeb. Element remoteusername musi pasować do twojej nazwy użytkownika na zdalnym serwerze, ale remotehostname może być dowolną nazwą hosta, która Ci odpowiada, nie musi pasować do niczego, co można rozwiązać.

Zobacz także:

• Ujawnij odwrotny punkt końcowy na host inny niż lokalny IP
• Wskazówki dotyczące korzystania z ControlMaster do utrzymania tunelu

Komentarze

• co z ssh -D. Wyjaśnij, używając tej samej metody.
• Serwery proxy SOCKS to nie to samo co tunele. Jeśli masz pytanie, jak ich używać, zadaj je .
• I ' Mam bardzo trudne chwile po tym wyjaśnieniu z powodu luźnego użycia terminów: serwer, klient, komputer lokalny, komputer zdalny, host, twójpublichost, localhost, zdalna nazwa hosta. Przy tych wszystkich luźnych i nieokreślonych terminach można założyć, że ktoś potrzebowałby aż 8 komputerów, aby to skonfigurować. Stwierdzam to, ponieważ we wszystkich innych aspektach wydaje się to bardzo dobrym wyjaśnieniem. Zmniejsz i zdefiniuj terminy.
• @ Rucent88, ' Nie wiem, jaka byłaby możliwa redukcja. Klient nawiązuje połączenie z serwerem. To ' terminologia stosowana na całym świecie. Maszyny lokalne i zdalne wydają się dość oczywiste. Jeśli po przeczytaniu dokumentacji ' nie masz pewności co do SSH lub ogólnej terminologii unixowej, ' na pewno ' nie będzie problemu ze znalezieniem tutaj osób bardzo chętnych do odpowiedzi na wszelkie pytania.
• @ghoti To ' jest rzeczywiście mylące, ponieważ lokalne a komputery zdalne są względne. Kiedy siedzę w miejscu pracy, mój komputer domowy jest zdalny, kiedy siedzę w domu, komputer w miejscu pracy jest zdalny. Serwer i klient również mylą, gdy mówimy o tunelowaniu. Na przykład jeśli łączę się z domem z pracy za pomocą ssh -R. Łączę się z pracą z komputera domowego, łącząc się z localhost. Zatem z punktu widzenia gniazd serwer sam w sobie jest komputerem domowym. Ale logicznie połączyłem się z komputerem w pracy. To ' jest mylące.

Narysowałem kilka szkiców

Maszyna, na której wpisane jest polecenie tunelu ssh, nazywa się »twój host« .

Wprowadzenie

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 oznacza: połącz się z ssh do connectToHost i przekaż wszystkie próby połączenia do lokalnego sourcePort do portu onPort na komputerze o nazwie forwardToHost, do którego można dotrzeć z komputera connectToHost.

2. zdalny: -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 oznacza: połącz się za pomocą ssh z connectToHost i przekaż wszystkie próby połączenia do zdalnego sourcePort na port onPort na komputerze o nazwie forwardToHost, do którego można się dostać z komputera lokalnego.

Dodatkowe opcje

• -f mówi ssh do samego tła po uwierzytelnieniu, więc nie musisz siedzieć i uruchamiać coś na zdalnym serwerze, aby tunel mógł pozostań przy życiu.
• -N mówi, że chcesz mieć połączenie SSH, ale tak naprawdę nie chcesz uruchamiać żadnych zdalnych poleceń. Jeśli wszystko, co tworzysz, to tunel, włączenie tej opcji oszczędza zasoby.
• -T wyłącza alokację pseudo-tty, co jest odpowiednie, ponieważ nie próba stworzenia interaktywnej powłoki.

Twój przykład

Trzeci obraz przedstawia ten tunel. Ale niebieski komputer o nazwie »Twój host« reprezentuje komputer, na którym ktoś uruchamia tunel SSH, w tym przypadku maszyna z firewallem.

Poproś więc kogoś o rozpoczęcie połączenia tunelowego ssh z Twoją maszyną. Polecenie powinno zasadniczo wyglądać jak

ssh -R 12345:localhost:22 YOURIP 

Teraz tunel jest otwarty.Możesz teraz łączyć się przez ssh z maszyną z zaporą ogniową przez tunel za pomocą polecenia

ssh -p 12345 localhost 

, które połączy się z Twoim własnym localhost (twoja maszyna) na porcie 12345, ale port 12345 jest przekierowywany przez tunel do portu 22 lokalnego hosta zapory ogniowej komputer (tj. sam komputer z zaporą ogniową).

Komentarze

• @erik, Jak narysowałeś te obrazy?
• I użyłem narzędzia do rysowania wektorów open source o nazwie Inkscape i moich myszy (no cóż, właściwie jest to trackball: Marble FX firmy Logitech).
• @ghoti: Domyślnie gniazdo nasłuchujące na serwerze (w moim obrazie -R żółty host zdalny) będzie powiązane tylko z interfejsem pętli zwrotnej. Można to zmienić, określając bind_address. Pusty adres bind_address lub adres „*” oznacza, że zdalne gniazdo powinno nasłuchiwać na wszystkich interfejsach. – Po prostu spróbuj: na niebieskim komputerze uruchom ssh -R 1234:localhost:8000 yellowcomputer. A także na niebieskim komputerze uruchom python -m SimpleHTTPServer (prosty serwer WWW na porcie 8000). Następnie w przeglądarce internetowej na żółtym komputerze otwórz adres URL http://localhost:1234, a zobaczysz, że działa.
• @erik, ach, mylące jest to, że moje oczy są źle – nie widziałem spacji przed remotehost w poleceniach '. Po bliższym przyjrzeniu się widzę, że Twoje diagramy nie ' w rzeczywistości nie odnoszą się do opcjonalnego adresu bind_address. Przepraszamy za zamieszanie.
• @briankip Tak, oczywiście. Przynajmniej jeśli chcesz nawiązać połączenie ssh z komputerem znajdującym się za zaporą (przez tunel lub bezpośrednio, jeśli zapora na to pozwala). To znaczy: Polecenie ssh, które piszesz na komputerze z zaporą ogniową, otwiera tylko tunel, ale nie uruchamia się ani nie działa jako ssh-daemon / -server. Twoje następne pytanie powinno brzmieć jak uruchomić sshd bez uprawnień roota (jeśli to jest twój problem). 🙂

Tunelowanie ssh działa przy użyciu już ustanowionego połączenia ssh do wysyłania dodatkowego ruchu.

Kiedy łączysz się ze zdalnym serwerem, zwykle masz tylko 1 kanał do normalnej interakcji użytkownika (lub 3 kanały, jeśli rozważasz oddzielne STDIN / STDOUT / STDERR). W dowolnym momencie lokalny lub zdalny proces ssh może otworzyć dodatkowe kanały w istniejącym połączeniu. Te kanały następnie wysyłają / odbierają ruch w tunelu. Podczas wysyłania lub odbierania jakiegokolwiek ruchu, proces ssh mówi po prostu „ten ruch jest dla kanału foobar”.

Zasadniczo działa to tak:

1. Mówisz ssh, aby zaczął nasłuchiwać na porcie XXXX i że każdy odebrany ruch powinien być tunelowany, a następnie ustawiony na YYYY na porcie ZZZZ.
2. Lokalny ssh zaczyna nasłuchiwać na porcie XXXX (zwykle na 127.0.0.1, ale można to zmienić).
3. Niektóre aplikacje otwierają połączenie z portem XXXX na komputerze lokalnym.
4. Lokalny ssh otwiera kanał do zdalnego ssh i mówi „wszelki ruch na tym kanale trafia na YYYY: ZZZZ
5. Zdalny ssh łączy się z YYYY: ZZZZ i odsyła „OK, kanał jest otwarty”
6. Teraz cały ruch przesyłany przez połączenie do portu XXXX na komputerze lokalnym jest zastępowany przez ssh do YYYY: ZZZZ.

Ten proces jest dokładnie taki sam dla tunelowania do przodu i do tyłu (wystarczy zamienić słowa „lokalny” i „zdalny” w powyższa procedura). Każda strona może uruchomić tunel nie musi nawet być przy pierwszym uruchomieniu ssh. Możesz otwierać tunele, gdy ssh już działa (patrz ESCAPE CHARACTERS, a konkretnie ~C).

Rola -R, -f, -L i -N, naprawdę powinieneś po prostu zajrzeć do strony podręcznika, zawiera ona najlepsze możliwe wyjaśnienie. Ale wspomnę o -R i -L.
-R mówi zdalnemu ssh nasłuchiwać połączeń i że lokalny ssh powinien łączyć się z rzeczywistym miejscem docelowym. -L mówi lokalnemu ssh, aby nasłuchiwał połączeń, a zdalny ssh powinien łączyć się z rzeczywistym miejscem docelowym.

Uwaga, jest to bardzo zgrubny opis, ale powinien dać ci wystarczająco dużo informacji, aby wiedzieć, co się dzieje

Jest to wyjaśnione w podręczniku SSH, a zwłaszcza różnice między -L (lokalnie) a -R (zdalne).

-L

-L [bind_address:]port:host:hostport

Określa, że port na hoście lokalnym (klienta) ma być przekierowany do danego hosta i port po stronie zdalnej .

Działa to poprzez przydzielenie gniazda do nasłuchiwania portu po stronie lokalnej, opcjonalnie powiązanego z określonym adresem bind_address.

Za każdym razem, gdy jest nawiązywane połączenie z tym portem, połączenie jest przekazywane przez bezpieczny kanał i nawiązywane jest połączenie do host port hostport z komputera zdalnego .

Poniższy przykład tuneluje sesję IRC z komputera klienta 127.0.0.1 (localhost) przy użyciu portu 1234 do zdalnego serwera server.example.com:

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

^{Uwaga: opcja -f Backgrounds ssh i zdalne polecenie sleep 10 są określone, aby dać czas na uruchomienie usługi, która ma być tunelowana.}

Przykład:

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

• -N Po połączeniu się po prostu zawieś (nie pojawi się zachęta powłoki)

  Nie wykonuj zdalnego polecenia.

• -L 22000 Połączenie zostanie nawiązane na porcie 22000 Twojego osobistego, L maszyna ocal

• localhost:11000 – remote.server.com upewni się, że drugi koniec tunelu to localhost, port 11000

^{Źródło: Ilustrowany przewodnik, samouczek, instrukcje dotyczące tunelowania ssh .}

-R

-R [bind_address:]port:host:hostport

Określa, że port na zdalnym hoście (serwerze) ma być przekierowany do g podany host i port po stronie lokalnej .

Działa to poprzez przydzielenie gniazda do nasłuchiwania port na po stronie zdalnej, a za każdym razem, gdy następuje połączenie z tym portem, połączenie jest przekazywane przez bezpieczny kanał, a połączenie jest na host port hostport z komputera lokalnego .

Przykład:

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

• -N Po połączeniu się po prostu zawieś (nie pojawi się monit powłoki)

  Nie wykonuj zdalnego polecenia.

• -R 22000 Połączenie zostanie nawiązane na porcie 22000 R komputera z emotikonami (w tym przypadku remote.server.com)

• Twój osobisty, lokalny komputer upewni się, że drugi koniec tunelu to localhost, port 11000

^{Źródło: Ilustrowany przewodnik, samouczek, instrukcje dotyczące tunelowania ssh .}

Komentarze

• ucho i usta dają jasno do zrozumienia, kto ' mówi i kto ' słucha!
• Uwielbiam twoje ilustracje!

Powiązanie z interfejsami sieciowymi podczas ustanawiania odwrotnych tuneli SSH jest wyjaśnione w tym poście . Oto przykład z 4 komputerami znajdującymi się w dwóch różnych sieciach: