Prędzej, czy później większość z nas, użytkowników komputerów, będzie miała do czynienia z pracą w środowisku nieprzyjaznym. Dla niektórych oznacza to sytuację, w której to chcąc zalogować się na swój domowy serwer FTP jest się narażonym na ujawnienie hasła. Dla innych - pracę za prostym firewall-em blokującym dostęp do bardziej, niż HTTP praktycznych usług znajdujących się np. poza granicami hotelowego intranetu. Spośród wielu rozwiązań to właśnie tunelowanie SSH może być tym, które okaże się dla nas najkorzystniejsze. SSH nie tylko pozwala na zachowanie bezpieczeństwa podczas zdalnej pracy, ale również na zabezpieczenie innych połączeń oraz ominięcie prostych ograniczeń typu blokada portów. Zapraszam zatem do zapoznania się z podstawami tunelowania SSH w środowisku Linuksa.
Nim przystąpimy do czysto technicznego opisu korzystania z tunelowania musimy zapoznać się ze środowiskiem w którym działamy. Przykład na którym będę bazować powinien wystarczyć do większości zastosowań. Wyobraźmy sobie następującą sytuację - w trakcie długiej i męczącej podróży zagranicznej trafiamy do pewnego taniego, ale nowoczesnego hotelu. Po wejściu do hotelowego pokoju ze zdziwieniem zauważamy na stole informację o tym, iż hotel udostępnia połączenie z Internetem. Nie zastanawiając się zbyt długo wyjmujemy laptopa ("Guest") i ochoczo zabieramy się za przeglądanie stron WWW. To jednak nie wszystko, co chcemy robić - mamy też ochotę połączyć się z naszym publicznie dostępnym kontem shell-owym ("public.shell.org" - nazwiemy je "Server"). Niestety - mało rozgarnięty administrator hotelowej sieci zablokował port 23 - wiemy już dlaczego hotel jest aż tak tani. Na całe szczęście, gdzieś w Internecie znajduje się również nasz domowy serwer - "Gate" (adres "4gate.net"). I to właśnie on pomoże nam uzyskać dostęp do zablokowanych zasobów.
Co tak właściwie mamy zamiar uczynić? Naszym celem jest uzyskanie dostępu do portu numer 23 na komputerze "Server" omijając zarazem hotelowy filtr tegoż portu. Wiemy, iż bezpośrednie połączenie z serwerem docelowym nie wchodzi w grę. Możemy jednak wykorzystać nasz domowy komputer - "Gate" - do tego, aby pomógł nam się uporać z tym ograniczeniem. Jesteśmy również świadomi tego, iż jedynym pewnym portem do którego mamy dostęp z wnętrza sieci hotelowej jest port numer 80. Idea polega zatem na tym, aby laptop "Guest" połączył się z komputerem "Gate" wykorzystując port 80, a dopiero ten ostatni nawiązał kontakt z komputerem "Server". Gdyby tak jeszcze udało nam się zmusić komputer domowy do pośredniczenia w wymianie danych między laptopem, a serwerem udostępniającym konta shell-owe to uzyskalibyśmy oczekiwany przez nas rezultat. Nie ma na co czekać - przejdźmy do konkretów.
Aby zrealizować powyższy zamysł "Guest" powinien posiadać dostęp do klienta ssh, a "Gate" dodatkowo powinien posiadać uruchomionego demona sshd. Ważnym jest to, aby ten ostatni został uruchomiony z opcją "-p 80" (np. "/usr/sbin/sshd -p 80") - służy ona do zmiany portu na którym ma nasłuchiwać serwer ssh (domyślnie 22). Niczego więcej od komputera domowego nie oczekujemy - no, może poza pracą 24/7. Powróćmy do naszego laptopa. Aby wykorzystać "Gate" do pośredniczenia między naszym hotelowym komputerem, a "public.shell.org" musimy wykonać następującą komendę - "ssh -f -N -L 6000:public.shell.org:23 -l login -p 80 4gate.net". Wytłumaczmy, co oznaczają te argumenty:
- -f - pracuj w tle
- -N - nie wykonuj żadnych komend po podłączeniu
- -L 6000:public.shell.org:23 - najważniejsza linijka - 6000 to port pod którym będzie dostępne konto shell-owe w komputerze "Guest"; "public.shell.org" to adres (z punktu widzenia "Gate" - zatem localhost oznaczałoby właśnie komputer domowy) serwera z którym chcemy nawiązać kontakt; 23 oznacza port ww. serwera
- -l login - użytkownik na komputerze domowym (jeżeli potrzebne jest hasło to zostaniemy poproszeni o jego podanie tuż po wywołaniu komendy)
- -p 80 - port na którym nasłuchuje demon SSH na komputerze domowym
- 4gate.net - adres komputera domowego
Po zaakceptowaniu komendy nastąpi połączenie z serwerem SSH na komputerze domowym oraz ewentualne pytanie o hasło dla podanego przez nas użytkownika. W tym też momencie każde połączenie z komputera "Guest" na porcie 6000 (porty poniżej 1024 wymagają uprawnień root-a na laptopie) zostanie wysłane na port 80 komputera "Gate". Połączenie to będzie na tym odcinku szyfrowane. Już na naszym domowym komputerze dane zostaną rozszyfrowane i posłane dalej - do "public.shell.org" na port 23. Efektem tego będzie możliwość wykonania polecenia "telnet localhost 6000" na laptopie i połączenie się z "public.shell.org:23". Miło, prawda?
Całość można przedstawić przy pomocy małego, ale treściwego szkicu, który powinien Wam uświadomić, na czym polega tunelowanie.

I to już koniec - w razie jakichkolwiek zastrzeżeń, czy też pytań proszę śmiało pisać. Konstruktywna krytyka jest zawsze mile widziana, a ja sam nieomylny nie jestem (szczególnie, iż wiedzę na ten temat zdobyłem dzisiaj). W najbliższym czasie powinienem zamieścić kolejny wpis - tym razem dotyczący tego, jak przy pomocy SSH ominąć proste proxy działające np. w firmowej sieci.