Nauka korzystania z tunelowania SSH w celu bezpiecznego surfowania. Protokoły tunelowe – czym są? Mapowanie dostępności

28 marca 2012 r. Autor: Jayson Broughton
w poradnikach SysAdmin

„Jeśli widzisz światło w tunelu, jest to światło nadjeżdżającego pociągu” – Robert Lowell. Kolejny dobry cytat. Ten artykuł dotyczy budowy tuneli za pomocą za pomocą protokołu SSH lub jak nazywam ten temat „tunele VPN dla biednych”. Wbrew podstawowym przekonaniom administratorów systemów, tunele SSH rzeczywiście mogą być całkiem niezłe przydatna rzecz zarówno dla techników, jak i użytek domowy. Mówię „wbrew przekonaniom administratorów systemu”, ponieważ tunele zwrotne lub ruch internetowy owinięty w SSH mogą przedostać się przez zapory ogniowe i filtry treści. Artykuł nie dotyczy jednak tego, jak można obalić korporacyjne zasady bezpieczeństwa, ale tego, jak tunelowanie SSH może uczynić nasze życie nieco mniej skomplikowanym.

Dlaczego tunele SSH zamiast VPN? OK, używam tego i tamtego w domu. Jeśli śledzisz mnie na jaysonbroughton.com, wiesz, że pracuję nad trójskładnikowym uwierzytelnianiem OpenVPN (nazwa użytkownika, certyfikat i hasło jednorazowe). Ale jeśli chcę sprawdzić jeden z kontrolowanych przeze mnie serwerów przez Androida, zajrzeć do komputera, na którym nie mam uprawnień administracyjnych (a przenośny klient OpenVPN ich potrzebuje), lub nawet chcę naprawić jakieś błędy za pomocą dostępu vnc przez Tunel SSH, to SSH to mój wybór sposobu zabezpieczenia ruchu.

Omówimy podstawy: jak zbudować tunel, co oznacza składnia poszczególnych poleceń, przykłady odwrotnych tuneli i sytuacje, w których należy zastosować to lub inne podejście. Omówiłem także pokrótce strukturę pliku konfiguracyjnego.

Więc och wymagania systemowe. Używam Debiana w wirtualne środowisko, więc Twoje wyniki mogą różnić się od moich. W związku z tym podaję informację o narzędziach: w użyciu jest serwer OpenSSH_5.3p1 oraz klienci OpenSSH 5.X w różnych wersjach. Zanim zagłębimy się w tunelowanie ssh, muszę powiedzieć: zanim zrobisz dziurę w bezpieczeństwie firmy za pomocą tunelu zwrotnego lub zawiń ruch http, upewnij się, że nie naruszasz żadnego stosu wewnętrznych przepisów, takich jak Zasady dopuszczalnego użytkowania Internetu. Oczywiste jest, że w tym przypadku Administratorzy systemu natychmiast Cię wytropią i usmażą, zwłaszcza jeśli korzystasz z tunelu, aby dostać się do serwera w pracy z domu. Jako Administrator Systemu czerpię ogromną przyjemność z odkrywania takich postaci. Uwierz mi, po krótkim sprawdzeniu okazuje się, że administratorzy systemu wcale nie idioci.

Cóż, zastrzeżenie zostało ogłoszone, możesz zaczynać.

Budowanie tuneli SSH jest dość prostą rzeczą. Zrozumienie tego, co się dzieje i sposobów uczenia się, może być nieco trudniejsze. Więc dam kilka typowe przypadki dostosować świadomość, zanim przejdziemy do szczegółów poleceń. Zanim urodziłam dzieci, sporo podróżowałam. Podczas moich podróży trafiałem do bardzo dziwnych hoteli, których pokoje były bardzo dziwne Punkty Wi-Fi dostęp. Czy na pewno chcesz połączyć się z hotelowym punktem dostępu, którego identyfikator SSID jest wpisany w nieprzetłumaczalnym gobbledygooku? Lub na lotnisku, gdzie jest ich kilka sieci otwarte? Kiedy jestem gdzieś w świecie zewnętrznym, wolę tunelować ruch sieciowy do mojego zrootowanego Androida poprzez serwer domowy. Kiedy mam laptopa w rękach, otwieram tunel ssh i przekierowuję ruch sieciowy przez skarpetki5, dzięki czemu cały ruch przychodzący do mnie jest szyfrowany. Ufam otwartym punktom WAP tylko wtedy, gdy mogę się po nich poruszać. O czym jeszcze zwykły tekst? Tuneluję ruch SMTP na moim komputerze przez mój serwer domowy i w niektórych miejscach widzę, że wychodzący SMTP jest zablokowany. Podobnie jest z POP3. Inny przykład: możesz zarządzać aplikacjami X poprzez tunel. Sesje VNC można zawijać w tunelu. Jedną z technik, którą zacząłem stosować wcześniej niż inne, były tunele odwrócone. W tym przypadku tworzysz tunel z serwera, który znajduje się z tyłu zapora ogniowa. Po zalogowaniu się do tego serwera SSH możesz ponownie nawiązać połączenie.

Przykłady

Zanim spojrzysz na stronę klienta, musisz wykonać pewne czynności po stronie serwera, korzystając z edycji plik konfiguracyjny sshd.config, w którym zalecam wprowadzenie następujących zmian. Przed wprowadzeniem zmian skopiuj oryginalną konfigurację dla bezpieczeństwa na wypadek, gdyby coś poszło nie tak.

Jeśli dokonałeś zmian, musisz ponownie uruchomić serwer sshd, aby je zastosować.

Przejdźmy do przełączników linii poleceń.

Typowy tunel ssh (bez tunelowania protokołu X) wygląda mniej więcej tak:

Jak można się domyślić, opcja -X tuneluje X. Pamiętaj jednak, że polecenie to przekopuje twoją aplikację ze zdalnej maszyny na twoją. maszyna klienta z Linuksem. Jeśli korzystasz z systemu Windows, po prostu zainstaluj Cygwin/X (http://x.cygwin.com/) na swoim komputerze samochód gościnny. Sam tego nie próbowałem, ale jak rozumiem, powinno to pomóc w uruchomieniu zdalna aplikacja X w Windowsie.

Podczas ustanawiania sesji VNC należy zachować ostrożność. Jeśli zdalny serwer VNC działa na porcie 5900, upewnij się, że nie łączysz się później z samym sobą. Sama sesja jest tunelowana podobnie jak w innych przypadkach za pomocą przezroczystego polecenia:

A teraz to masz, odwrotny tunel.

Dla przejrzystości Daddoo i nerdboy4200 z #linuxjournal połączyli siły i stworzyli Mscgen, program, który analizuje sekwencję wiadomości i buduje wizualny diagram wymiany wiadomości dla różnych protokołów. Jest to oczywiście oprogramowanie typu open source i dość okropne, jeśli chodzi o wygląd (http://www.mcternan.me.uk/mscgen/). Dla przypadku tunelu odwracalnego za pomocą swojego produktu zbudowali diagram (wtedy autor wstawił do swojego tekstu diagram, na którym nic nie widać - ok. przeł.).

Wniosek

Zatem to, co możesz zrobić z tunelowaniem, ogranicza jedynie Twoja wyobraźnia. Podaliśmy tutaj tylko kilka przykładów. Być może w kolejnych postach opowiem jak poprawnie skonfigurować SSH po stronie klienta.

Wysłane przez: admin 17 października 2017

Jak działa tunelowanie SSH

Tunel SSH, czyli przekazywanie portów SSH, jak nazywa to man(1) ssh, to opcjonalna funkcja protokołu działająca jako dodatek do znanej zwykłej sesji SSH. Tunel SSH umożliwia wysłanie pakietu TCP z jednej strony połączenia SSH na drugą stronę i rozgłaszanie nagłówka IP zgodnie z wcześniej ustaloną regułą podczas procesu transmisji.

Bardzo łatwo jest zrozumieć, jak działa tunel SSH: jeśli wyobrażasz sobie go jako połączenie typu punkt-punkt. Podobnie jak w PPP, każdy pakiet, który trafi na jeden koniec połączenia, zostanie wysłany i odebrany na drugim końcu tunelu. Ponadto, w zależności od adresu odbiorcy określonego w nagłówku IP, pakiet zostanie albo przetworzony przez odbiorczą stronę tunelu (jeśli pakiet jest przeznaczony bezpośrednio dla niej), albo kierowany dalej do sieci (jeśli odbiorcą jest inna sieć węzeł).

Główna różnica między tunelem SSH a połączeniem PPP polega na tym, że tunelem SSH można opakować tylko ruch TCP. (Uwaga: istnieje kilka sposobów przekazywania protokołu UDP przez gniazdo TCP w tunelu SSH, ale to rozwiązanie wykracza poza zakres tego artykułu).

Druga różnica dotyczy połączenia punkt-punkt ruch przychodzący można zainicjować z dowolnej strony, natomiast w przypadku tunelu SSH konieczne jest jawne ustawienie „punktu wejścia” dla ruchu. „Punkt wejścia” to parametr formularza<адрес>:<порт>, wskazując, które gniazdo należy otworzyć, aby wejść do tunelu (od strony lokalnej czy zdalnej sesji SSH).

Oprócz punktu wejścia należy dodatkowo określić regułę formularza<адрес>:<порт>, zgodnie z którym podczas transmisji należy przepisać nagłówek (a dokładniej adres i port docelowy) pakietu TCP. Punkt wejścia można ustawić z dowolnego końca tunelu. Za ten parametr odpowiadają klawisze –L (lokalny) i –R (zdalny). Przez lokalne i zdalne rozumiemy boki tunelu z punktu widzenia strony inicjującej, czyli hosta, który ustanawia sesję SSH.

Jak dotąd wygląda to trochę zagmatwane, więc spójrzmy na to na konkretnym przykładzie.

Bezpośredni tunel SSH - zapewniający dostęp do serwera za NAT

Alex pracuje jako administrator systemu w małej firmie produkującej szarlotki o nazwie Qwerty Cakes. Cała sieć firmowa zlokalizowana jest w jednej domenie rozgłoszeniowej 192.168.0.0/24. Służy do uzyskiwania dostępu do Internetu router programowy oparty na systemie Linux, którego adres to 192.168.0.1 po stronie sieci firmowej i 1.1.1.1 po stronie Internetu. Demon OpenSSD jest uruchomiony na routerze, do którego można uzyskać dostęp poprzez gniazdo 1.1.1.1:22. Wewnątrz sieci, wewnętrzny portalu korporacyjnego, w którym Alex musi wprowadzić zmiany do jutrzejszego ranka interfejs sieciowy. Jednak Alex nie chce zostawać do późna w pracy, chce uzyskać dostęp do portalu ze swojego domu komputer domowy z adresem 2.2.2.2.

Alex wraca do domu i po obiedzie nawiązuje następujące połączenie z routerem firmowym:

Co się stało? Alex nawiązał sesję SSH między adresami 2.2.2.2 i 1.1.1.1, otwierając jednocześnie lokalny „punkt wejścia” do tunelu 127.0.0.1:8080 na swoim komputerze domowym:

alex@Alex-PC:~$ sudo lsof -nPi | grep8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (SŁUCHAJ)

Każdy pakiet TCP, który dotrze do gniazda 127.0.0.1:8080 z komputera Alexa, zostanie wysłany przez połączenie punkt-punkt wewnątrz Sesje SSH, w tym przypadku adres docelowy w nagłówku TCP zostanie przepisany z 127.0.0.1 na 192.168.0.2, a port z 8080 na 80.

Teraz, aby dostać się do portalu swojej firmy, Alex musi jedynie wpisać w przeglądarce:

Jak idą pakiety sieciowe w tunelu SSH

Przyjrzyjmy się bliżej, co stało się z pakietem TCP przechodzącym przez tunel SSH:

1. Pakiet TCP o adresie źródłowym 127.0.0.1 i adresie docelowym oraz porcie 127.0.0.1:8080 wszedł do gniazda 127.0.0.1:8080, otwierane procesowo ssh;

2. Proces ssh odebrał pakiet, zgodnie z regułą translacji, przepisał adres docelowy i port na 192.168.0.2:80 i wysłał go w ramach sesji SSH do strony zdalnej 1.1.1.1;

3. Proces sshd na routerze 1.1.1.1 odebrał pakiet i po sprawdzeniu adresu docelowego wysłał go do hosta 192.168.0.2, przepisując jednocześnie adres źródłowy z 127.0.0.1 na adres własnego interfejsu 192.168.0.1, dzięki czemu odbiorca, który nic nie wie o istnieniu tunelu SSH, zwrócił pakiet do routera, a nie wysłał go do własnego hosta lokalnego 127.0.0.1.

alex@Alex-PC:~$ ssh -L

127.0.0.1:8080:192.0.0.2:80 [e-mail chroniony]

W w tym przykładzie, jeśli portal lub inny zasób, do którego Alex musi uzyskać dostęp, znajdował się na samym routerze (na przykład pod adresem 192.168.0.1:80), wówczas polecenie wyglądałoby tak:

Jeśli usługa jest dostępna na localhost (na przykład lokalny serwer SQL), możesz uzyskać do niej dostęp:

alex@Alex-PC:~$ ssh -L

127.0.0.1:13306:127.0.0.1:3306 [e-mail chroniony]

Konstrukcje takie jak -L 127.0.0.1:80:127.0.0.1:80 mogą na pierwszy rzut oka wyglądać dość dziwnie. Ale nie ma w nich nic skomplikowanego, jeśli pamięta się, że decyzja o routingu pakietów jest podejmowana po odległej stronie tunelu. Trzeba pamiętać o podstawowej zasadzie: druga para<адрес>:<порт>przetwarzane przez odległą stronę tunelu.

Dlatego pakiet o adresie docelowym 127.0.0.1 w regule translacji będzie przetwarzany przez drugą stronę sesji SSH i nic więcej.

Jak już zapewne się domyślasz, punkt wejścia do tunelu można utworzyć nie tylko na interfejsie pętli zwrotnej. Jeśli tunel ma być dostępny nie tylko dla lokalnego hosta, ale także dla innych uczestników sieci, możesz to określić prawdziwy adres interfejs.

alex@Alex-PC:~$ ssh -L

10.0.0.5:8080:192.0.0.2:80 [e-mail chroniony]

Komputer Alexa Alex-PC ma dwa Interfejs sieciowy z adresami 2.2.2.2 i 10.0.0.5. Podczas procesu ustanawiania sesji ssh otworzy gniazdo 10.0.0.5:8080 na komputerze Alex-PC. Teraz Alex może uzyskać dostęp do portalu 192.168.0.2:80 ze swojego laptopa o adresie 10.0.0.4 i wszystkich swoich sieć domowa 10.0.0.0/24.

Odwrotny tunel SSH — udostępnij swoje zasoby Internetowi

Jak już mówiłem, punkt wejścia do tunelu można otworzyć nie tylko od strony inicjatora sesji ssh, ale także od strony zdalnej, czyli od tej, do której nawiązujemy sesję ssh. Aby to zrobić, użyj opcji -R zamiast opcji -L. Po co to jest?

Na przykład, aby móc opublikować usługę lokalną dla zdalny dostęp.

Web działa na laptopie Alexa serwer Apache dostępny pod adresem 127.0.0.1 z kopią testową portalu firmowego. Alex musi mieć dostęp do serwer internetowy swoim współpracownikom w celu przetestowania interfejsu. Ogólnie rzecz biorąc, do takich celów byłoby miło, gdyby Alex zaimplementował bardziej niezawodną piaskownicę testową. Ale ponieważ nasz Alex jest w tym artykule niczym więcej niż wirtualną postacią, aby zademonstrować działanie tunelu SSH, ustanawia sesję między swoim laptopem a routerem Linux. Za pomocą parametru -R otwiera port 8080 na wewnętrznym interfejsie routera z adresem 192.168.0.1, który odnosi się do gniazda 127.0.0.1:80 jego testowego serwera WWW.

Jak widać, na routerze proces sshd otworzył lokalne gniazdo 8080

alex@Router: ~$

sudo lsof -nPi | grep8080

sshd

17233 alex 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (SŁUCHAJ)

Zobaczmy co się stanie z pakietem TCP wysłanym z komputera 192.168.0.200 do portalu testowego opublikowanego pod adresem 192.168.0.1:8080:

1. Pakiet TCP o adresie źródłowym 192.168.0.200 oraz adresie docelowym i porcie 192.168.0.1:8080 trafi do gniazda 192.168.0.1:8080, otwartego przez proces sshd;

2. Proces sshd po odebraniu pakietu, zgodnie z regułą translacji, przepisze adres docelowy i port z 192.168.0.1:8080 na 127.0.0.1:80 i wyśle go w ramach sesji SSH do strony inicjującej. 2.2. 2,2;

3. Proces ssh na laptopie Alexa, po odebraniu pakietu i sprawdzeniu jego adresu docelowego, przepisze adres nadawcy z 192.168.0.200 na adres pętli zwrotnej i wyśle go do lokalnego gniazda 127.0.0.1:80 otwartego przez Apache proces.

Jeden ważna uwaga, który zostawiłem na koniec artykułu.

Jeżeli przy otwieraniu punktu wejścia do tunelu zamiast adresu rzeczywistego interfejsu zostanie użyty localhost, to można go pominąć, skracając w ten sposób polecenie o

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [e-mail chroniony]

zanim

alex@Alex-PC:~ssh -L

8080:192.0.0.1:80 [e-mail chroniony]

Ten ważna cecha składnia będzie dla nas przydatna w poniższym przykładzie.

Podwójne tunelowanie

Przyjrzyjmy się trochę więcej złożony przykład. Użytkownik SQL-Tester znajdujący się za NAT musi uzyskać dostęp do bazy danych na Serwer SQL, który również stoi za NAT. SQL-Tester nie może nawiązać połączenia bezpośrednio z serwerem, ponieważ w sieci serwerów NAT nie ma odpowiednich tłumaczeń. Jednakże z obu hostów można nawiązać sesję SSH z serwerem pośrednim 3.3.3.3.

Zainstaluj z serwera SQL Połączenie SSH z serwerem 3.3.3.3 i otwartym portem 13306 na interfejsie pętli zwrotnej serwera 3.3.3.3, który odnosi się do lokalnej usługi SQL działającej na lokalnym gnieździe 127.0.0.1:3306 serwera SQL:

dbuser@serwer SQL:~$ ssh -R 13306:127.0.0.1:3306

[e-mail chroniony]

Teraz z hosta klienta SQL-Tester nawiązujemy połączenie z 3.3.3.3 i otwieramy port 3306 w interfejsie zwrotnym klienta, co z kolei odnosi się do 127.0.0.1:13306 na serwerze 3.3.3.3, co... odnosi się do adresu 127.0.0.1:3306 na serwerze SQL. To proste.

tester@Tester SQL:~$ ssh -L

3306:127.0.0.1:13306 [e-mail chroniony]

Tunel dynamiczny - SSH jako proxy Socks

W przeciwieństwie do tuneli z wyraźnym wskazaniem zasad tłumaczenia, tunel dynamiczny działa na zupełnie innej zasadzie. Zamiast określać mapowanie adresu:portu jeden do jednego dla każdego adresu docelowego i portu, otwierasz gniazdo po lokalnej stronie sesji SSH, co zamienia Twój host w serwer proxy SOCKS4/SOCKS5. Spójrzmy

Przykład:

Utwórz dynamiczne gniazdo tunelowe 127.0.0.1:5555 na hoście klienta w ramach sesji SSH z serwerem 2.2.2.2

użytkownik@klient:~$ ssh -D 5555 [e-mail chroniony]

Sprawdzanie, czy port jest otwarty

użytkownik@klient:~$ sudo lsof -nPi | grep 5555

7284 użytkownik 7u

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (SŁUCHAJ)

A proxy rejestrujemy w ustawieniach przeglądarki lub innego oprogramowania obsługującego proxy SOCKS.

Teraz cały ruch przeglądarki będzie przechodził przez serwer proxy SOCKS w ramach szyfrowanego połączenia SSH między hostami 1.1.1.1 i 2.2.2.2.

Jak korzystać z protokołu SSH w systemie Microsoft Windows?

Po przeczytaniu artykułu możesz zdecydować, że wszystkie zalety tuneli SSH są dostępne tylko dla użytkowników systemów typu Unix. Jednak tak nie jest. Prawie wszyscy klienci terminali dla systemu Windows korzystający z protokołu SSH obsługują tunelowanie.

Od pewnego czasu można używać systemu Windows nie tylko jako Klient SSH. Istnieje możliwość zainstalowania serwera SSH w systemie Windows.

Kiedy używać tuneli SSH?

Oczywiście, aby stworzyć trwałe tunele na serwerach bojowych trzeba skorzystać ze specjalnego oprogramowanie. Ale dla szybkie rozwiązanie zadania związane z przekierowaniem portów, rozwiązywaniem problemów, uzyskiwaniem szybkiego zdalnego dostępu i ogólnie rozwiązaniami Szczególnym zadaniem„tu i teraz” często pomocne jest wykorzystanie tuneli SSH.

Za ich pomocą można budować całe sieci, tunele w tunelach, a także łączyć rodzaje tuneli. Dzięki temu możesz szybko dostać się do miejsc, do których wydawałoby się to niemożliwe.

Oprócz swojej głównej funkcji, protokół SSH zapewnia administratorowi wiele użyteczne narzędzia, w tym artykule porozmawiamy o tworzeniu Tunel VPN przy użyciu protokołu SSH.
Tunelowanie SSH- najprostszy i szybki sposób zdobądź tunel do serwera Linux, ponieważ Pakiet OpenSSH najprawdopodobniej jest już na nim zainstalowany, a powstały tunel nie będzie miał problemów z NAT.

Taki tunel jest prosty, ale nie niezawodny, ponieważ wykorzystuje połączenie TCP i nie zawiera wbudowanych mechanizmów przywracania połączenia po przerwie.
Tunel SSH najlepiej używać do testów(przykładowo, jeśli chcesz przesłać pakiety UDP na zdalny serwer, przekierowanie portów przez SSH w tym przypadku nie pomoże), a dla stałych tuneli użyj specjalnie do tego zaprojektowanych protokołów, takich jak OpenVPN, PPTP, L2TP, IPSec, GRE , itp. .d. (Wszystkie przykłady poleceń w artykule są poprawne dla CentOS 6)

Instalacja i konfiguracja

Zainstaluj pakiet OpenSSH z repozytoriów, jeśli nie jest jeszcze zainstalowany:

mniam, zainstaluj openssh openssh-server openssh-clients

Aby serwer pozwolił na korzystanie z tuneli należy włączyć opcję PermitTunnel w pliku ustawień serwera OpenSSH (najczęściej /etc/ssh/sshd_config) i zrestartować serwer OpenSSH (service sshd restart).

Zezwolenie na tunel tak

Na końcu pliku ustawień serwera mogą znajdować się sekcje ustawień dla konkretnych hostów, użytkowników, grup użytkowników itp.
Podobne sekcje zaczną się od linii

Gospodarz...
Lub
Mecz...

Przed opisanymi sekcjami należy dodać opcję PermitTunnel.

Korzystanie z tuneli SSH

We wszystkich przykładach zostanie użyty serwer OpenSSH dostępny pod adresem 192.168.1.100.

Prosty tunel SSH

Aby utworzyć najprostszy tunel SSH, możesz uruchomić polecenie

sudo ssh -w 7:7 -l root 192.168.1.100

Opcja odpowiada za utworzenie tunelu

W<номер_локального_интерфейса>:<номер_удалённого_интерфейса>

Zamiast numeru interfejsu lokalnego i/lub zdalnego można użyć wartości „dowolny”, wówczas zostanie utworzony kolejny wolny interfejs TUN.

Po przejściu uwierzytelnienia sudo i SSH na hostach lokalnych i zdalnych powinien pojawić się wyłączony interfejs tun7.

Aby skorzystać z tunelu należy włączyć interfejsy i skonfigurować je z adresami IP z tej samej podsieci, na przykład tak:

# na localhoście
# na zdalnym hoście

Teraz host lokalny będzie miał dostęp do hosta zdalnego pod adresem 10.255.255.1 poprzez zaszyfrowany tunel (pod warunkiem, że zapory ogniowe hosta lokalnego i zdalnego pozwalają na takie połączenia).

Dużą wadą tego schematu jest konieczność dostępu na zdalny serwer przez SSH z uprawnieniami superużytkownika (ponieważ do utworzenia interfejsu TUN wymagane są uprawnienia superużytkownika), podczas gdy wielu administratorów systemów woli odmawiać dostępu rootowi przez SSH ze względu na większe bezpieczeństwo. Eliminację tej wady opisano w następnym akapicie.

Tunel SSH z nieuprzywilejowanymi uprawnieniami użytkownika

Aby utworzyć tunel SSH z uprawnieniami użytkownika nieuprzywilejowanego, należy najpierw utworzyć interfejs TUN należący do tego użytkownika (w każdym przypadku do utworzenia interfejsu TUN potrzebne będą uprawnienia superużytkownika na zdalnym hoście).
Aby utworzyć interfejs TUN w starszych Dystrybucje Linuksa Używane jest narzędzie tunctl (musi być dostępne w repozytoriach dystrybucji), w nowszych dystrybucjach funkcjonalność ta jest zawarta w pakiecie iproute2. Aby określić, jak utworzyć interfejs TUN na hoście, uruchom polecenie

Jeśli polecenie wyświetli błąd

Obiekt „tuntap” jest nieznany, spróbuj „ip help”.

Oznacza to, że musisz użyć narzędzia tunctl, po jego wcześniejszej instalacji (yum install tunctl), w przeciwnym razie polecenie powinno wyświetlić listę interfejsów TUN/TAP na hoście.

Przejdźmy do konfiguracji.

Utwórz nieuprzywilejowanego użytkownika na zdalnym hoście:

dodaj przez użytkownika ssh_tunnel

Utwórz interfejs TUN należący do tego użytkownika

Używając tunctla:

tunctl -n -t tun7 -u ssh_tunnel -g ssh_tunnel

Używając iproute2:

ip tuntap dodaj dev tryb tun7 tun użytkownik ssh_tunnel grupa ssh_tunnel

Podłączenie tunelu SSH przebiega podobnie jak w poprzednim przykładzie:

# na localhoście
sudo ssh -w 7:7 -l ssh_tunnel 192.168.1.100
ifconfig tun7 w górę 10.255.255.2 pointopoint 10.255.255.1
# na zdalnym hoście
ifconfig tun7 w górę 10.255.255.1 pointopoint 10.255.255.2

Tworzenie użytkownika wyłącznie do tunelowania SSH

W w tym momencie Rozważone zostanie uniemożliwienie nieuprzywilejowanemu użytkownikowi korzystania z konsoli przy jednoczesnym umożliwieniu mu tunelowania SSH. Nie będzie działać ustawienie powłoki „/bin/false” lub „/sbin/nologin” dla użytkownika, ponieważ w takim przypadku użytkownik w ogóle nie będzie mógł nawiązać połączenia SSH.

Aby wejść w opisane ograniczenia należy dodać poniższe linie na końcu pliku ustawień serwera OpenSSH (/etc/ssh/sshd_config) i zrestartować serwer OpenSSH (service sshd restart)

Dopasuj użytkownika ssh_tunnel
X11Nr spedycyjny
Zezwól na przekazywanie Tcp tak
ZezwólAgentowi na przekazywanie nr
BramaPorty nr
ForceCommand echo „Tego konta można używać wyłącznie do tunelowania”; kot

Ograniczenie w tym przykładzie jest nałożone na wcześniej utworzonego użytkownika ssh_tunnel. Parametr ForceCommand powoduje, że użytkownik automatycznie wykonuje polecenie „echo „To konto może być używane tylko do tunelowania”; cat” natychmiast po podłączeniu. Uniemożliwi to użytkownikowi normalne korzystanie z konsoli, ponieważ jeśli proces cat zostanie zabity przez naciśnięcie Ctrl+C, połączenie SSH zostanie zamknięte.

SSH-tunelowanie może pomóc nie tylko w sprawach, w których konieczne jest przesyłanie niezaszyfrowanego ruchu przez szyfrowane połączenie, ale także wtedy, gdy nie masz dostępu do zasobu w sieci, ale dostęp jest konieczny.

Przyjrzyjmy się tworzeniu i konfigurowaniu kilku opcji.

I tak mamy serwer, nazwijmy to gospodarz-1. Dla niego mamy pełny dostęp tylko przez SSH- ale musimy otworzyć Kocur, działający na porcie 8082 - do którego nie mogą nas przepuścić.

Rozważymy opcję z ustawieniem Okna I Kit.

Otwarcie SSH- połączenie z do wymaganego serwera, zalogujmy się.

Określamy następujące parametry:

Port źródłowy: dowolny nieużywany port w systemie;
Port docelowy: 127.0.0.1:8082

Kliknij Dodać, Następnie Stosować.

Przejdź do ustawień przeglądarki i ustaw parametry proxy:

Teraz pozostaje już tylko otworzyć w przeglądarce stronę http://localhost:3002 - i trafiamy na stronę Kocur na serwerze gospodarz-1.

Jeśli tunel nie działa, sprawdź na serwerze, czy włączone jest przekazywanie pakietów. W pliku /etc/ssh/sshd_config znajdź i odkomentuj linię:

Zezwól na przekazywanie Tcp tak

I ponowne uruchomienie SSHd:

# service sshd restart Zatrzymywanie sshd: [ OK ] Uruchamianie sshd: [ OK ]

Inny przykład - mamy ten sam serwer zewnętrzny, z którego mamy normalny dostęp do wszelkich zasobów w Internecie. Ale z miejsca pracy mamy dostęp i jest zamknięte.

Wykonujemy podobne działania, ale z niewielkimi różnicami. Ustawienia w Kit:

Port źródłowy - pozostaw to samo, ale zamiast tego Lokalny- wybierać Dynamiczny. Kliknij Dodać, Stosować.

Przejdźmy do ustawień przeglądarki:

Należy pamiętać, że typem serwera proxy nie jest tutaj HTTP, ale SOCKS.

Ciesz się dostępem do swoich ulubionych stron.

I ciekawszy przypadek.

Mamy tak samo gospodarz-1. Oprócz tego istnieje drugi serwer, nazwijmy to gospodarz-2. Dodatkowo posiadamy maszynę z Okna, któremu należy przyznać dostęp do zasobu TeamCity na serwerze gospodarz-1 na porcie 8111. W tym przypadku dostęp z Okna-posiadamy tylko maszyny na serwer gospodarz-2 i tylko do portu 22.

Na początek podnosimy tunel pomiędzy gospodarz-1 I gospodarz-2. Wykonujemy dalej gospodarz-1:

$ ssh -f -N -R host-2:8082:localhost:8111 nazwaużytkownika@host-2

Otwieramy więc tunel, który lokalnie (na gospodarz-1) patrzy na port 8111, a po drugiej stronie znajduje się maszyna gospodarz-2, na którym otwiera się port 8082 i czeka na połączenia przychodzące. Przy odbiorze pakietów na porcie 8082 (i tylko przez interfejs lo0! to ważne) - przekieruje je do maszyny gospodarz-1 portu 8111.

Jeśli chodzi o interfejs lo0. Po zainstalowaniu SSH-tunnel, nawet przy podaniu zewnętrznego IP maszyny - połączenie jest nawiązywane tylko z localhost, tj. 127.0.0.1 .

Spójrzmy na gospodarz-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* SŁUCHAJ -

Aby to zmienić należy edytować plik konfiguracyjny demona sshd - /etc/ssh/sshd_config i zmienić parametr:

#GatewayPorts nr

Ale nie zrobimy tego teraz, to tylko uwaga.

Kontynuujmy. Przejdźmy do konfiguracji Kit Na naszym Okna-samochód. Tutaj wszystko jest proste - używamy przykładu 1 z tego artykułu, wystarczy zmienić port na żądany (nawiasem mówiąc, na zrzucie ekranu tam jest). Połączmy się Kit do gospodarza gospodarz-2, organizować coś tunel. Zmień ustawienia w przeglądarce pełnomocnik— i otrzymamy to, czego potrzebujemy, podaj adres http://localhost:3002:

SSH jest dość wrażliwy na utratę pakietów, dlatego tunele mogą być często przerywane.

Aby tego uniknąć, możesz pobawić się parametrami w pliku ustawień sshd - /etc/ssh/sshd_config:

#TCPKeepAlive tak #ServerAliveInterval #ServerAliveCountMax

Lub użyj narzędzia autossh.

Od redaktora AnswIT:

W tym przykładzie, jeśli portal lub inny zasób, do którego Alex potrzebował dostępu, znajdował się na samym routerze (na przykład pod adresem 192.168.0.1:80), wówczas polecenie wyglądałoby następująco:

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [e-mail chroniony]

Jeśli usługa jest dostępna na localhost (na przykład lokalny serwer SQL), to uzyskaj do niej dostęp
można uzyskać dostęp:

alex@Alex-PC:~$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 [e-mail chroniony]

Konstrukcje takie jak -L 127.0.0.1:80:127.0.0.1:80 mogą na pierwszy rzut oka wyglądać dość dziwnie. Ale nie ma w nich nic skomplikowanego, jeśli pamiętasz, że decyzja o tym
routing pakiet jest odbierany po odległej stronie tunelu. Trzeba pamiętać o podstawowej zasadzie: druga para
<адрес>:<порт>przetwarzane przez odległą stronę tunelu.
Dlatego pakiet o adresie docelowym 127.0.0.1 w regule translacji będzie przetwarzany przez drugą stronę sesji SSH i nic więcej.

alex@Alex-PC:~$ ssh -L
10.0.0.5:8080:192.0.0.2:80 [e-mail chroniony]

Komputer Alexa Alex-PC ma dwa interfejsy sieciowe o adresach 2.2.2.2 i 10.0.0.5. Podczas procesu ustanawiania sesji ssh otworzy gniazdo 10.0.0.5:8080 na komputerze Alex-PC. Teraz Alex może uzyskać dostęp do portalu 192.168.0.2:80 ze swojego laptopa o adresie 10.0.0.4 i ze wszystkich
Twoja sieć domowa 10.0.0.0/24.

Odwrotny tunel SSH — udostępnij swoje zasoby Internetowi

Serwer WWW Apache działa na laptopie Alexa i jest dostępny
pod adresem 127.0.0.1 z kopią testową portalu firmowego. Alex musi przyznać swojemu serwerowi dostęp do serwera WWW
współpracownikom do przetestowania interfejsu. Ogólnie rzecz biorąc, do takich celów byłoby miło, gdyby Alex zaimplementował bardziej niezawodną piaskownicę testową. Ale ponieważ w tym artykule nasz Alex jest niczym więcej niż wirtualną postacią, on
demonstracja działania tunelu SSH
sesję między laptopem a routerem z systemem Linux. A użycie parametru -R otwiera port 8080
wewnętrzny interfejs routera o adresie 192.168.0.1, który odnosi się do gniazda 127.0.0.1:80 jego testowego serwera WWW.

Jak widać, na routerze proces sshd otworzył lokalne gniazdo 8080

alex@Router: ~$
sudo lsof -nPi | grep8080

sshd
17233 alex 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (SŁUCHAJ)

Zobaczmy co się stanie z pakietem TCP wysłanym z komputera 192.168.0.200 do portalu testowego opublikowanego pod adresem 192.168.0.1:8080:
1. Pakiet TCP o adresie źródłowym 192.168.0.200 oraz adresie docelowym i porcie 192.168.0.1:8080 trafi do gniazda 192.168.0.1:8080, otwartego przez proces sshd;

2. Proces sshd po odebraniu pakietu, zgodnie z regułą translacji, przepisze adres docelowy i port z 192.168.0.1:8080 na 127.0.0.1:80 i wyśle go w ramach sesji SSH do strony inicjującej. 2.2. 2,2;

Jak widać zasady transmisji są bardzo proste. Host otwierający gniazdo tunelu tłumaczy adres docelowy i port zgodnie z regułą translacji. Host po przeciwnej stronie tunelu zmienia adres źródłowy i port zgodnie ze swoją tablicą routingu. Tablica routingu jest konieczna, po pierwsze, aby wysłać pakiet we właściwym kierunku, a po drugie, aby wygenerować
zastąpienie adresu źródłowego adresem interfejsu, z którego zostanie wysłany pakiet.
Jedna ważna uwaga, którą zostawiłem na końcu artykułu.
Jeżeli przy otwieraniu punktu wejścia do tunelu zamiast adresu rzeczywistego interfejsu zostanie użyty localhost, to można go pominąć, skracając w ten sposób polecenie o

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [e-mail chroniony]

alex@Alex-PC:~ssh -L
8080:192.0.0.1:80 [e-mail chroniony]

Ta ważna cecha składni będzie przydatna w poniższym przykładzie.

Podwójne tunelowanie

Spójrzmy na nieco bardziej złożony przykład. Użytkownik SQL-Tester znajdujący się za NAT musi uzyskać dostęp do bazy danych na serwerze SQL, który również znajduje się za NAT. Nie można zainstalować testera SQL
połączenie bezpośrednio z serwerem, ponieważ w sieci serwerów NAT nie ma odpowiednich tłumaczeń. Można jednak ustanowić sesję SSH z obu hostów za pomocą pośrednika
serwer 3.3.3.3.

Z serwera SQL nawiązujemy połączenie SSH z serwerem 3.3.3.3 i otwieramy je na interfejsie zwrotnym serwera
3.3.3.3 port 13306, odnoszący się do lokalnej usługi SQL działającej na lokalnym gnieździe 127.0.0.1:3306 serwera SQL:

dbuser@serwer SQL:~$ ssh -R 13306:127.0.0.1:3306
[e-mail chroniony]

Teraz z hosta klienta SQL-Tester nawiązujemy połączenie z 3.3.3.3 i otwieramy port 3306 na interfejsie zwrotnym klienta, co z kolei odnosi się do 127.0.0.1:13306 na serwerze
3.3.3.3, który... odnosi się do 127.0.0.1:3306 na serwerze SQL. To proste j

tester@Tester SQL:~$ ssh -L
3306:127.0.0.1:13306 [e-mail chroniony]

Tunel dynamiczny - SSH jako proxy Socks

W przeciwieństwie do tuneli z wyraźnym wskazaniem zasad tłumaczenia, tunel dynamiczny działa na zupełnie innej zasadzie. Zamiast określać mapowanie adresu:portu jeden do jednego dla każdego adresu docelowego i portu, użytkownik
otwórz gniazdo po lokalnej stronie sesji SSH, co zamieni Twój host w serwer proxy działający przy użyciu protokołu SOCKS4/SOCKS5. Spójrzmy
przykład:

Utwórz dynamiczne gniazdo tunelowe 127.0.0.1:5555 na hoście klienta w ramach sesji SSH z serwerem 2.2.2.2

użytkownik@klient:~$ ssh -D 5555 [e-mail chroniony]

Sprawdzanie, czy port jest otwarty

użytkownik@klient:~$ sudo lsof -nPi | grep 5555

ssh
7284 użytkownik 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (SŁUCHAJ)

I rejestrujemy serwer proxy w ustawieniach przeglądarki lub dowolnego
inne oprogramowanie obsługujące proxy SOCKS.

Teraz cały ruch przeglądarki będzie przechodził przez serwer proxy SOCKS w ramach szyfrowanego połączenia SSH
między hostami 1.1.1.1 i 2.2.2.2.

Jak korzystać z protokołu SSH w systemie Microsoft Windows?

Po przeczytaniu artykułu możesz zdecydować, że wszystkie zalety tuneli SSH są dostępne tylko
użytkownicy systemów uniksowych. Jednak tak nie jest. Prawie wszystko dla systemu Windows korzystające z protokołu SSH obsługuje tunelowanie.

Od pewnego czasu można używać systemu Windows jako czegoś więcej niż tylko klienta SSH. Mam okazję.

Kiedy używać tuneli SSH?

Oczywiście, aby stworzyć trwałe tunele na serwerach bojowych trzeba skorzystać ze specjalnego oprogramowania. Aby jednak szybko rozwiązać problem przekierowania portów, rozwiązywania problemów, uzyskania szybkiego zdalnego dostępu i ogólnie rozwiązania konkretnego problemu „tu i teraz”, często pomocne jest użycie tuneli SSH.

Za ich pomocą można budować całe sieci, tunele w tunelach, a także łączyć rodzaje tuneli. Dzięki temu możesz szybko dostać się do miejsc, do których wydawałoby się to niemożliwe.