Zabawa w SSHowanego

Rozwiązania
Zabawa w SSHowanego
Zabawa
w SSHowanego
Wojciech Terlikowski
[email protected]
W czasach gdy niemal każdy komputer podłączony jest do sieci, czy to niewielkiej domowej
lub osiedlowej, czy też do Internetu niesłychanie ważnym zagadnieniem staje się zapewnienie
bezpieczeństwa komunikacji między stacjami roboczymi. Protokół SSH, dzięki silnej ochronie
kryptograficznej, znakomicie się do tego nadaje. Artykuł ma na celu przybliżenie czytelnikowi
szerokich możliwości oferowanych przez SSH również w mniej znanych zastosowaniach takich jak
przekierowanie portów i tworzenie tuneli.
Z
SSH zetknął się chyba każdy, kto pracował z
systemami linuksowymi. Bezpieczna powłoka (secure shell) towarzyszy większości administratorów w wykonywaniu codziennych
obowiązków, jest również niezastąpiona dla wielu użytkowników wszędzie tam, gdzie szybko i sprawnie trzeba
wykonać jakieś czynności na zdalnym systemie, a jednocześnie mieć poczucie bezpieczeństwa jakie daje szyfrowany protokół.
Szyfrowany telnet
innymi przez SSH jest brak szyfrowania transmisji, szczególnie dotkliwy podczas procesu uwierzytelniania.
Taka luka bezpieczeństwa pozwala na podsłuchanie sesji i zdobycie informacji nie tylko o tym jakie polecenia wykonujemy na zdalnym systemie, ale również poznanie naszego loginu i hasła, co może w konsekwencji prowadzić do
przejęcia kontroli nad naszym kontem. Przeprowadzenie takiego ataku nie wymaga głębokiej wiedzy ani bardzo skomplikowanych narzędzi. Wystarczy prosty program podsłuchujący ruch w sieci (sniffer) jakich wiele bezpłatnych można znaleźć w Internecie. Używanie telnetu było do zaakceptowania w sieciach, których użytkownicy mieli do siebie dużo zaufania i nie obawiali się, że ktoś będzie chciał się włamać do ich komputera. Pamiętam, że jeszcze na początku
studiów do niektórych serwerów wydziałowych mieliśmy
dostęp przez telnet, ale z czasem był on zastępowany przez
SSH. Wówczas była to jeszcze nowość, ale dająca więcej
bezpieczeństwa, bo szyfrowana.
Kiedy po raz pierwszy miałem okazję korzystać z zasobów Internetu, jeszcze w latach dziewięćdziesiątych ubiegłego stulecia, do zalogowania się na zdalne serwery używałem telnetu.
Jest to proste narzędzie, pozwalające na otwarcie sesji
na innym komputerze w sieci. Połączenie do serwera telnetu umożliwia wykonywanie poleceń na zdalnym systemie. Rozwiązanie to ma jednak wadę, która zadecydowała
o jego niemal całkowitym zaniku, przynajmniej w środowi- Trochę historii
skach uniksowych i uniksopodobnych, w tym w Linuksie. Protokół SSH został opracowany w połowie lat dziewięćSłabością, która zadecydowała o wyparciu telnetu między dziesiątych na Politechnice w Helsinkach przez jednego z
42
styczeń 2010
Rozwiązania
Zabawa w SSHowanego
pracowników naukowych – Tatu Ylönena jako
odpowiedź na atak, polegający na podsłuchaniu
i przechwyceniu haseł przesyłanych przez protokoły nieszyfrowane. Celem projektu było zastąpienie narzędzi takich jak telent, rlogin i rsh
przez rozwiązania podobne, ale zapewniające
wyższy stopień bezpieczeństwa dzięki ochronie kryptograficznej. Po piętnastu latach możemy powiedzieć, że niewielu linuksowym administratorom zdarza się wykorzystywać rlogin,
czy rsh, są pewnie i tacy, którzy nie wiedzą,
że coś takiego istniało, natomiast niemal wszyscy znają SSH.
Kilka lat po opracowaniu pierwszej wersji protokołu powstała, najpopularniejsza
obecnie, implementacja zarówno serwera jak
i klienta – OpenSSH. Projekt ten jest rozwijany przez zespół OpenBSD na licencji BSD.
Wolna licencja jak również bogactwo możliwości jakie daje OpenSSH, pozostając w pełnej zgodności ze specyfikacją protokołu, zapewniły tej implementacji dużą popularność.
Obecnie OpenSSH jest wykorzystywane przez
wiele systemów operacyjnych jak Sun Solaris,
Mac OS X, BSD, Novell Netware, IBM AIX,
HP UX, urządzenia sieciowe Cisco, Juniper,
HP, Dell, Alcatel oraz niemal wszystkie dystrybucje Linuksa.
Niedawno ukazała się nowa wersja
OpenSSH 5.3. Chociaż nie wnosi ona znacznych zmian do programu, to ma znaczenie historyczne, ponieważ została wydana dziesięć
lat po powstaniu projektu i publikacji pierwszej wersji produktu.
Podczas instalacji serwera warto zwrócić uwagę na moment przedstawiony na Rysunku 2
Metody generowania kluczy i kryptografia
asymetryczna mogą być temetem osobnego artykułu, tu skupię się na kwestiach najistotniejszych
dla użytkownika. Przede wszystkim, klucz prywatny jest tajny i może być znany tylko właścicielowi, w tym wypadku serwerowi SSH. Klucz
publiczny jest jawny, ale stanowi parę do prywatnego i dlatego oba muszą być wygenerowane razem. W związku z tym klucze nie mogą być dostarczane z pakietem oprogramowania, jak na
przykład plik z domyślną konfiguracją, ale trzeba je wygenerować każdorazowo podczas instalacji programu. Ponowna instalacja OpenSSH,
związana np. ze zmianą dystrybucji, spowoduje,
że powstanie nowa para kluczy. Spowoduje to,
że odciski palca (fingerprints) serwera zapamiętane przez klientów staną się niekatulane i będzie
je trzeba zaktualizować.
Po pomyślnie zakończonej instalacji przystępujemy do konfiguracji serwera
OpenSSH. Będziemy modyfikować prosty,
tekstowy plik z konfiguracją: /etc/ssh/sshd_
config. Bezpieczeństwo wymaga, aby serwer
używał protokołu w wersji drugiej (SSH-2).
Zapewnia to wpis Protocol 2. W pierwotnej
specyfikacji wykryto poważne luki bezpieczeństwa, dlatego została zastąpiona przez
SSH-2. Wersja druga nie tylko jest bezpieczniejsza od SSH-1, ale dodaje do protokołu nowe możliwości. Wspierają ją wszystkie współczesne klienty SSH. Obie wersje
nie są ze sobą kompatybilne i czasami trzeba
w kliencie wymusić użycie SSH-1 jeśli będziemy chcieli połączyć się z serwerem, który nie wspiera SSH-2. Na szczęście takich
serwerów jest coraz mniej.
Drugą opcją konfiguracyjną, którą zmienimyna serwerze jest wyłączenie możliwości logowania na konto roota. W tym celu wystarczy
wpis PermitRootLogin no. W dalszym ciągu
możemy wykonywać czynności administracyjne logując się przez SSH na konto zwykłe-
Zabawa się rozpoczyna
Jak wspomniałem, OpenSSH jest dostępne
w repozytoriach niemal każdej dystrybucji Li- Rysunek 1. Popularność różnych implementacji ssh od czasu pojawienia się OpenSSH. Wyraźnie widać,
nuksa, więc zainstalowanie go nie stanowi żad- że OpenSSH z ponad 80% udziałem jest zdecydowanie najczęściej używaną implementacją. Źródło: [3]
nego problemu. SSH to program sieciowy dlatego do przetestowania go potrzebować będziemy
sieci komputerowej, a w najprostszym przypadku dwóch komputerów. Jeden z nich posłuży za
serwer SSH, nazwijmy go bolek, drugi to komputer biurkowy – lolek, na którym zainstalujemy
klienta SSH. Z tej maszyny będziemy się logować do bolka. Oba komputery pracują pod kontrolą dystrybucji Debian GNU/Linux dlatego by
zainstalować serwer OpenSSH należy wykonać
na bolku:
jas@bolek$ sudo aptitude install
openssh-server
natomiast na lolku instalujemy klienta poleceniem:
jan@lolek$ sudo aptitude install
openssh-client
Rysunek 2. Instalacja serwera OpenSSH. Widoczny moment generowania kluczy kryptograficznych
www.lpmagazine.org
43
Rozwiązania
Zabawa w SSHowanego
go użytkownika, a następnie uzyskując uprawnienia roota poprzez skorzystanie z polecenia
su - lub odpowiednio skonfigurowanego pakietu sudo. Takie ograniczenie wydaje się niepotrzebnym utrudnieniem dla użytkowników
sieci lokalnych, ale jest bezwzględnie zalecane jeżeli serwer ma być dostępny z Internetu. Potwierdzają to moje własne doświadczenia. Zdarzyło mi się, że w kilka minut po podłączeniu nowego serwera do Internetu znalazłem w dzienniku systemowym ślady dziesiątek nieudanych prób zalogowania przez SSH
na konto roota podejmowanych przez komputery z całego świata. Gdybym nie zablokował
tej możliwości, przypuszczalnie musiałbym
Teraz możemy połączyć się przez lolka
odłączyć komputer od Sieci i zacząć usuwać z serwerem SSH bolek. Robimy to wydając
skutki włamania.
polecenie:
Po takich zmianach ustawień należy zrestartować usługę ssh:
jan@lolek$ ssh jas@bolek
jas@bolek$ sudo /etc/init.d/ssh
Domyślna konfiguracja klienta jest wystarczająca, ale w razie potrzeby można ją zmienić
modyfikując plik /etc/ssh/ssh_config na komputerze lolek. Podobnie jak na serwerze jest to
prosty plik tekstowy.
Rysunek 3. Połączenie do SSH po zmianie odcisku palca. Po usunięciu wpisu z ~/.ssh/known_hosts znów
jesteśmy proszeni o potwierdzenie tożsamości serwera
Rysunek 4. Przykład zastosowania ssh do tunelowania X11. Gra Kmahjongg uruchomiona na zdalnym
serwerze
44
lub:
restart
styczeń 2010
jan@lolek$ ssh bolek -l jas
gdzie bolek jest serwerem, na który się logujemy, natomiast jas to identyfikator użytkownika na tym serwerze. Zamiast nazwy komputera
(hostname) można podać jego adres IP lub pełną nazwę domenową np. bolek.example.com,
co jest konieczne gdy komputer znajduje się
w Internecie w zupełnie innej domenie niż nasza. Jeśli na obu systemach używamy tego samego loginu można go nie podawać przy nawiązaniu połączenia, wtedy SSH zaloguje nas
na konto o takiej samej nazwie jak lokalne.
Jeśli pierwszy raz łączymy się do serwera, SSH wyświetli odcisk palca (patrz rys. 3)
i zapyta czy na pewno na tej maszynie chcemy otworzyć sesję. Po potwierdzeniu tożsamości serwera zostaniemy zapytani o hasło na
komputerze bolek, a jego odcisk palca zostanie zapisany w pliku ~/.ssh/known_hosts. Od
tej pory, jeśli serwer zmieni odcisk zostaniemy o tym poinformowani przy próbie logowania (patrz Rysunek 3). Sytuacja taka następuje gdy serwer został zastąpiony nową maszyną, lub gdy nastąpiła reinstalacja systemu,
w tym pakietu OpenSSH. Zazwyczaj administratorzy powiadomią nas wcześniej o takim zdarzeniu. Jeśli mamy pewność, że odcisk
faktycznie się zmienił i łączymy się z właściwym komputerem należy usunąć linijkę z pliku ~/.ssh/known_hosts o numerze podanym w
komunikacie. W naszym przypadku jest to linia numer 7. Przy kolejnej próbie logowania
zostaniemy poproszeni o akceptację odcisku
palca nowego klucza.
Po poprawnym zalogowaniu możemy
pracować na serwerze bolek, wydając polecenia jakbyśmy mieli otwartą lokalną konsolę. Sesję kończymy komendą exit lub skrótem klawiszowym [Ctrl+D] tak samo jak
w przypadku pracy lokalnej.
Czy używanie ssh jest równie wygodne
jak praca lokalna? A co z aplikacjami graficznymi? Spróbujmy uruchomić grę Kmahjongg.
Niestety, próba zakończy się wyświetleniem komunikatu błędu cannot connect to X server, co oznacza , że serwer X nie znalazł odpowiedniego miejsca do wyświetlenia graficznego
okienka gry. Nie wyświetli go w tekstowej konsoli, w której działa ssh, może jednak wykorzystać do tego graficzny pulpit komputera lolek.
Rozwiązania
Zabawa w SSHowanego
Taki efekt można osiągnąć przez odpowiednią
konfigurację X11, tak by programy uruchamiane na bolku były wyświetlane na ekranie lolka.
Można również wykorzystać do tego SSH. Protokół ten, daje możliwość przekierowania X11
(X11 forwarding), z której skorzystamy. Wystarczy rozpocząć nową sesję SSH dodając
przy uruchamianiu przełącznik -X:
kładanych przez protokół X, czasem użycie
tej opcji może okazać się konieczne. Jeśli zachodzi potrzeba uruchomienia wielu programów graficznych na zdalnym komputerze, to
wartym rozważenia rozwiązaniem jest VLC.
Za jego pomocą można udostępnić cały graficzny pulpit klientowi usługi. W wielu przypadkach może to okazać się wygodniejsze
i bardziej efektywne od zastosowania przejan@lolek$ ssh -X bolek -l jas
kierowania X. SSH jest wciąż bardzo popularną i często jedyną tego typu usługą dostępOperacja taka ustawia przekierowanie X11 ną na serwerze.
na klienta SSH i sprawia, że programy graficzne działające na bolku będą wyświetla- Nie tylko zdalna sesja
ły swe okna na lolku. Starujemy ponownie Poznaliśmy już możliwości protokołu SSH
kmahjongg:
związane z pracą na zdalnym systemie, ale
co zrobić gdy chcemy przenieść pliki z jednejas@bolek$ kmahjongg &
go komputera na drugi? W przypadku plików
tekstowych można je skopiować do schowDodanie znaku &, powoduje uruchomienie ka i wkleić do edytora otwartego na zdalgry w tle, tak by nie blokować dostępu do nym komputerze. Może to być nawet wykonsoli na bolku. Po chwili na ekranie kom- godne dopóki nie pojawi się konieczność
putera lolek pojawi się się okienko Kmah- kopiowania dużych plików, lub zbiorów bijongg. Inną opcją, pozwalającą na przekiero- narnych. Rodzina protokołów RSH miała w
wanie X11 jest -Y, tak zwane zaufane prze- tym celu RCP, którego używało się podobkierowanie X (trusted X forwarding). Jest nie jak zwykłego kopiowania plików poleceono mniej bezpieczne, ponieważ nie spełnia niem cp. Ponadto istnieje protokół FTP, słuwszystkich standardów bezpieczeństwa na- żący do transferowania plików między komputerami w sieci, jednak żaden z nich nie szyListing 1. Przykładowy skrypt zmieniający konfifruje transmisji. Na szczęście w rodzinie progurację wielu serwerów za pomocą SSH
tokołów SSH znalazły się ich odpowiedniki:
SCP – bezpieczne kopiowanie (secure copy)
for SERVER in bolek reksio uszatek
i SFTP – bezpieczny protokół transferu plikoralgol
ków (secure file transfer protocol). Tego drudo
giego nie należy mylić z FTPS – rozszerzessh jas@$SERVER 'echo
niem FTP. Zarówno SCP jak i SFTP są szynameserver 10.12.15.254 > /etc/
frowane i zapewniają takie samo bezpieczeńresolv.conf'
stwo transmisji jak SSH. Oba są dostarczadone
ne z OpenSSH, więc żeby z nich korzystać
nie musimy niczego instalować dodatkowo.
Listing 2. Generowanie kluczy kryptograficz-
Polecenia scp używamy podobnie jak zwykłego cp:
jan@lolek$ scp jas.jpeg jas@bolek:
/tmp/
Jak widać na przykładzie różnicą jest człon jas@bolek: wskazujący, że kopiowanie ma odbywać się do katalogu na serwerze bolek z uprawnieniami użytkownika jas. Należy zwrócić
uwagę na dwukropek (:) rozdzielający część
sieciową od ścieżki w systemie plików. Jeśli chcemy skopiować plik w przeciwną stronę
z serwera bolek na komputer lolek, robimy to
poleceniem:
jan@lolek$ scp jas@bolek:/tmp/
obraz.png ./obrazek.png
Spowoduje to skopiowanie pliku /tmp/
obraz.png do bieżącego katalogu i nadanie mu
nazwy obraz.png. Jedną z bardziej użytecznych opcji używanych z scp jest -r. Pozwala
ona na rekurencyjne skopiowanie całego katalogu wraz z zawartością. Polecenie:
jan@lolek$ scp -r jas@bolek:/etc/ ./
skopiuje całą zawartość katalogu /etc na serwerze bolek do bieżącego katalogu. Składnia
scp dopuszcza również użycie znaków specjalnych powłoki np.:
jan@lolek$ scp jas@bolek:~/zdjecia/
*.jpeg ~/
skopiuje wszystkie pliki o rozszerzeniu jpeg
(*.jpeg) z katalogu zdjecia do katalogu domowego lokalnego użytkownika. Symbole występujące w ścieżkach serwera są interpretowane
nych wykorzystywanych do autoryzacji w SSH
jan@lolek$ ssh-keygen
Generating public/private rsa key
pair.
Enter file in which to save the key
(/home/jan/.ssh/id_rsa):
Created directory '/home/jan/
.ssh'.
Enter passphrase (empty for no
passphrase):
Enter same passphrase again:
Your identification has been saved
in /home/jan/.ssh/id_rsa.
Your public key has been saved in
/home/jan/.ssh/id_rsa.pub.
The key fingerprint is:
2d:4f:15:7b:60:51:66:ac:5b:90:32:
58:83:a1:b4:28 jas@lolek
Rysunek 5. Okno programu gftp z otwartą sesją SSH
www.lpmagazine.org
45
Rozwiązania
Zabawa w SSHowanego
przez jego powłokę nie przez scp. W wyniku
czego skrypt, korzystający z takich symboli będzie działał różnie z różnymi maszynami w zależności od tego jaki system pracuje po stronie
serwera i jakiej powłoki używa. Takiego uzależnienia od platformy nie ma drugi z wymienionych protokołów służących do kopiowania
plików. SFTP, bo o nim mowa, pozwala na interaktywną pracę na zdalnym systemie plików
podobnie jak FTP. Logujemy się poleceniem:
jan@lolek$ sftp jas@bolek
a następnie za pomocą poleceń takich jak get i
put możemy kopiować pliki z i na serwer. Jeśli
ktoś preferuje pracę w środowisku graficznym
to może skorzystać z jednej z wielu graficznych
nakładek na SFTP takich jak gftp czy WinSCP.
śli uda się napisać skrypt, który wykona za nas
chociaż część żmudnej pracy to zaoszczędzony czas możemy poświęcić na przyjemniejsze
zajęcia, na przykład czytanie ostatniego numeru Linux+. Przypuśćmy, że administrujemy
siecią, w której właśnie zmienił się adres serwera DNS. Nowy adres to 10.12.15.254. Musimy teraz zmienić konfigurację wszystkich
serwerów w sieci, modyfikując zawartość pliku /etc/resolv.conf. Jeśli są to trzy serwery to
można zalogować się na każdy z nich osobno i
ręcznie wykonać polecenie:
echo 'nameserver 10.12.15.254' >
/etc/resolv.conf
Kiedy będzie ich kilkadziesiąt to zadanie takie
staje się żmudne i czasochłonne. Ponadto nie
trudno tu o pomyłkę. Z pomocą w takiej syUżycie SSH w skryptach
tuacji przychodzi nam SSH. Pozwala ono na
W pracy administratora (i nie tylko) bardzo li- wykonanie polecenia w trybie wsadowym, bez
czy się umiejętność automatyzacji zadań. Je- otwierania interaktywnej sesji, a po zakończe��������
������
��������
������
�������
���������
������
����������
������������������
���
���������������������
�������������
����
Rysunek 6. Zastosowanie odwrotnego tunelu SSH do połączenia do serwera znajdującego się za zaporą ogniową
niu powraca do powłoki klienta, z której zostało wywołane.
jan@lolek$ ssh jas@bolek 'echo
nameserver 10.12.15.254 > /etc/
resolv.conf'
Takie polecenie powoduje wywołanie komendy
echo na serwerze bolek z przekierowaniem wyjścia do pliku /etc/resolv.conf na tymże serwerze,
a następnie powrót do powłoki na lolku. W rezultacie zawartość pliku /etc/resolv.conf zostanie
zmieniona na nameserver 10.12.15.254, czyli to co chcieliśmy osiągnąć. Teraz wystarczy wywołać skrypt dla każdego z naszych serwerów i
rekonfiguracja gotowa.
Bardzo wygodne, prawda? Jednak skrypt
nie działa tak sprawnie jak byśmy sobie tego
życzyli, ponieważ przy logowaniu do każdego z serwerów trzeba podawać hasło. I na to
jest rada. Uwierzytelnienie przez podanie hasła nie jest jedyną możliwością w SSH. Istnieje wariant logowania przez klucz publiczny (public key) oraz za pomocą GSSAPI. To
ostatnie pozwala na zarządzanie autoryzacją
w SSH za pośrednictwem zewnętrznych mechanizmów, takich jak Kerberos. Skupmy się
na metodzie klucza publicznego, ponieważ jest
prosta i nie wymaga od nas używania dodatkowego oprogramowania. Najpierw musimy mieć
parę kluczy, która będzie identyfikować naszego klienta, czyli użytkownika jan na komputerze lolek, logującego się na konto jaś na komputer bolek. Do generowania kluczy użyjemy
programu ssh-keygen dostarczanego razem
z OpenSSH. Hasło (paraphrase) do klucza pozostawiamy puste.
Następnie kopiujemy wygenerowany
klucz publiczny do pliku .ssh/authorized_keys
w katalogu domowym użytkownika, na którego będziemy się logować na serwerze bolek.
jan@lolek$ ssh jas@bolek 'mkdir ~/
.ssh/'
jan@lolek$ scp ~/.ssh/id_rsa.pub
jas@bolek:~/.ssh/authorized_keys
Przy wykonywaniu polecenia scp po raz ostatni podajemy hasło. Następne logowanie do
bolka będzie możliwe już bez hasła. Dzięki temu możemy wykonać skrypt sprawniej,
gdyż nie będzie wymagał od nas ingerencji
i podawania haseł.
Bardzo pomocne przy administrowaniu
komputerem, są potoki (pipes). Dzięki nim
możemy łączyć możliwości wielu niedużych
programów jak na przykład cat, grep czy wc
w skomplikowane narzędzia. W SSH również
nie mogło zabraknąć obsługi potoków. Załóż-
Rysunek 7. Konfiguracja Firefoksa do użycia serwera pośredniczącego
46
styczeń 2010
Rozwiązania
Zabawa w SSHowanego
my, że uruchamiamy program i chcemy, by
wszystkie jego krytyczne komunikaty (zaczynające się od ERROR:) były zapisywane na zdalnym serwerze. Rejestrowanie zdarzeń z krytycznych usług na innych komputerach jest dobrą praktyką bezpieczeństwa. Bardziej zaawansowane konfiguracje można osiągnąć za pomocą demona syslog. W tym momencie wystarczy
nam proste użycie SSH.
Przy użyciu potoków łączymy funkcjonalności
programu grep, który wybiera tylko interesujące nas komunikaty ssh, zapewniającego transfer logów na inny serwer i cat, zapisującego je
do pliku logów.
Kopię zapasową serwisu www można wykonać poleceniem:
den z zainstalowanym tam klientów konsolowych. Na dłuższą metę okaże się to niezbyt wygodne. Uciążliwa będzie na przykład obsługa załączników, wymagająca przesyłania plików między serwerem a komputerem domowym. Do zastosowania wygodniejszego rozwiązania, wykorzystującego przekierowanie portów SSH, potrzebna nam będzie podstawowa wiedza na temat konfiguracji protokołów pocztowych. Wystarczy wiedzieć, na którym porcie słucha tunelowana usługa. Najprostszym źródłem informacji na ten temat jest plik /etc/services. Można dowiedzieć się z niego, że protokołowi POP3 odpowiada port 110, zaś SMTP – 25. W przykładach
z tunelami połączenia SSH będą nawiązywane w
obie strony – również do naszego komputera domowego, więc przyda się zainstalowanie na nim
serwera OpenSSH.
Polecenie pozwalające na zabezpieczenie transmisji SMTP będzie wyglądało następująco:
jan@lolek$ tar -czf - /var/www/* |
jan@lolek$ ssh [email protected]
ssh jas@bolek 'cat > ~/backup/backup_
ia.edu.pl
jan@lolek$ ./skrypt.sh | grep
'^ERROR:' | ssh jas@bolek 'cat >>
/var/log/skrypt.log'
www.tar.gz'
Alternatywnym rozwiązaniem jest spakowanie
plików lokalnie, a następnie przesłanie paczki
za pomocą SCP. Wersja z użyciem potoku jest
jednak bardziej elegancka i oszczędza nam zamieszania z tymczasowym plikiem archiwum.
Istnieje również opcja OpenSSH, pozwalająca na kompresję przesyłanego strumienia danych. Włącza się ją za pomocą przełącznika
-C. W czasach rozpowszechnienia sieci szerokopasmowych nie jest to często używana opcja,
ale niekiedy może usprawnić pracę. Zwłaszcza
wtedy, gdy trzeba będzie przesyłać dobrze kompresujące się dane, np. pliki tekstowe, przez sieć
o niedużej przepustowości.
Wchodzimy w tunel
Tunele sieciowe są potężnym i bardzo wygodnym narzędziem, dzięki któremu można zabezpieczyć transmisję protokołów nieszyfrowanych
oraz ominąć niektóre ograniczenia wprowadzone przez zapory ogniowe. W SSH tunele realizowane są za pomocą przekierowania portów (port
forwarding). Rozważmy prostą sytuację, w której
dzięki tunelowaniu, uzyskamy bezpieczny dostęp
do nieszyfrowanej usługi pocztowej. Na serwerze wydziałowym mamy konto pocztowe i konto powłoki dostępne przez SSH. Niestety administrator udostępnił pocztę tylko przez nieszyfrowane protokoły POP3 i SMTP. Jeśli nie chcemy,
aby nasze dane były przesyłane niezabezpieczonym kanałem możemy posłużyć się SSH. Najprostszym rozwiązaniem jest zalogowanie się
do powłoki serwera i obsługa poczty przez je-
-L 8025:localhost:25
Składnia komendy jest trochę skomplikowana.
Pierwsza część ssh [email protected] jest już znana. Opcja -L oznacza, że
SSH będzie nasłuchiwać na lokalnym porcie o
numerze 8025 i to jest jeden koniec tunelu. Drugi podawany jest po dwukropku w postaci host:
port, w naszym przypadku localhost:25. Należy zaznaczyć, że zamiast 8025 można wybrać którykolwiek z wolnych portów, jednak do
użycia numerów 1024 i mniejszych trzeba mieć
uprawnienia roota. Kolejną ważną i powodującą prawdopodobnie najwięcej nieporozumień
rzeczą jest nazwa hosta na drugim końcu tunelu. Jest ona podawana względem komputera, na
który się logujemy, czyli w tym przypadku localhost oznacza poczta.naszauczelnia.edu.pl.
W ten sposób zestawiliśmy szyfrowany tunel
z lokalnego portu 8025 do portu 25 na wydziałowym serwerze poczty. Skoro nauczyliśmy się
już tunelowania możemy przekierować drugi
port – ten do odbierania poczty.
jan@lolek$ [email protected].
edu.pl -L 8025:localhost:25 -L 8100:
localhost:110
Teraz wystarczy skonfigurować ulubionego
klienta poczty i wskazać mu localhost:8025 jako serwer SMTP do wysyłania poczty, zaś localhost:8110 do jej odbierania. Dzięki temu możemy jednocześnie cieszyć się komfortowym
korzystaniem z poczty i bezpieczeństwem jakie daje ochrona kryptograficzna kanału. Warto przy tym pamiętać, że tunel działa tak długo jak długo otwarta jest sesja SSH, po zakończeniu połączenia do localhost:8025 i localhost:
8110 przestaną działać.
Gdy już poznaliśmy podstawy tuneli załóżmy bardziej skomplikowaną sytuację. Wewnątrz sieci akademickiej znajduje się serwer, na którym wykonujemy projekt serwisu
WWW. Mamy dostęp do niego zarówno przez
SSH na standardowym porcie 22 jak i HTTP na
porcie 80, ale tylko z komputerów w sieci wydziałowej. Co zrobić gdy chcemy popracować
nad projektem siedząc w domu? Możemy zalogować się przez SSH na serwer pocztowy,
z którego mamy bezpośredni dostęp do komputera projektowego. Nie jest to jednak zbyt wygodne, ponieważ na obu tych serwerach mamy
do dyspozycji wyłącznie przeglądarki tekstowe,
które nie wspierają nowoczesnych technologii
WWW takich jak Java Script czy CSS. Najwy-
Listing 3. Plik konfiguracyjny tsocks.conf
local = 192.168.0.0/255.255.255.0
local = 10.0.0.0/255.0.0.0
server = 127.0.0.1
server_type = 5
server_port = 8080
Listing 4. Instalacja pakietu tsocks na serwerze w DMZ
jan@firmowy$ wget http://ftp.icm.edu.pl/pub/Linux/debian/pool/main/t/
tsocks/tsocks_1.8beta5-9.1_amd64.deb
jan@firmowy$ scp tsocks_1.8beta5-9.1_amd64.deb jan@serwerfirmowy:~/
jan@firmowy$ ssh jan@serwerfirmowy
jan@serwerfirmowy$ su jan@serwerfirmowy# cd ~jan
jan@serwerfirmowy#dpkg -i tsocks_1.8beta5-9.1_amd64.deb
www.lpmagazine.org
47
Rozwiązania
Zabawa w SSHowanego
godniej byłoby użyć lokalnego Firefoksa z Firebugiem i innymi dodatkami, ale bezpośrednio
na adres serwera projektowego się nie połączymy. W takiej sytuacji możemy zestawić tunel
SSH za pomocą polecenia:
jan@lolek$ ssh [email protected]
lnia.edu.pl -L 9080:projekty:80 -L
9022:projekty:22
Teraz, po wpisaniu adresu http://localhost:
9080/janek/ przeglądarka wyświetli projekt
strony, nad którym można dalej bez przeszkód
popracować. Dostęp do powłoki serwera projektowego uzyskujemy przez SSH:
jan@lolek$ ssh localhost -l janek -p
9022
gdzie janek to nazwa naszego użytkownika
na serwerze projektowym, a opcja -p pozwala
otworzyć połączenie na porcie innym niż standardowy 22, w tym wypadku na 9022.
Czasem zabezpieczenia sieci wydziałowej
są bardziej rygorystyczne i nie pozwalają na
logowanie się na serwer projektowy z serwera pocztowego. Wtedy, by móc pracować nad
projektem z domu, potrzebny będzie komputer
domowy z serwerem SSH osiągalny z sieci Internet. W czasie pobytu na uczelni musimy dostać się do komputera projektowego i otworzyć
z niego sesję SSH na serwerze domowym za
pomocą polecenia.
janek@projekty$ ssh -R 9022:
localhost:22 [email protected]
Opcja -R oznacza, że zestawiony zostanie tunel odwrotny z lolka na serwer projektowy.
Po powrocie do domu można wykorzystać ten
tunel by zalogować się bezpośrednio do komputera projektowego wywołując komendę:
jan@lolek$ ssh localhost -l janek -p
9022
W Sieci
•
•
•
•
•
•
•
•
•
48
oraz zestawienia drugiego tunelu po por- mocą przekierowania portów SSH warto roztu HTTP.
ważyć kilka przypadków jak z podobnie zabezpieczonej sieci się wydostać.
jan@lolek$ ssh localhost -l janek -p
Wiele sieci firmowych blokuje dostęp do
9022 -L 9080:localhost:80
niektórych usług, np. wybranych serwerów
WWW, pozostawiając tylko te uznane za nieZnów składnia polecenia staje się nieco skom- zbędne. Niestety, może to skutecznie utrudnić
plikowana. Czytelnika może zaniepokoić uży- pracę i warto poznać sposób na obejście takiego
cie localhost. Część ssh localhost -l ja- ograniczenia. Z pomocą przyjdzie serwer SSH
nek -P 9022 jest już znana i wbrew pozo- dostępny w Internecie. Najlepiej gdyby była to
rom powoduje zalogowanie na serwer projek- maszyna, na której mamy uprawnienia roota,
towy mimo, iż używamy adresu localhost, aby w razie potrzeby móc skonfigurować SSH.
co sugerowałoby raczej lokalny komputer. Tu- Załóżmy, że administrator sieci firmowej zablonel odwrotny łączy port 9022 hosta lokalnego kował nasze ulubione serwisy WWW, ale poi port SSH maszyny projektowej, dlatego te- zostawił możliwość logowania się na serwery
raz połączenie do localhost:9022 otwiera se- SSH. Możemy użyć jednego z takich serwerów
sję na zdalnym komputerze. Druga część po- jako pośrednika sieciowego (proxy) i przy jelecenia również jest nam znana: otwiera tunel go pomocy uzyskać dostęp do zablokowanych
z portu 9080 lokalnego komputera na port 80 usług. Polecenie:
komputera z którym się łączymy. Tu localhost oznacza serwer projektowy. Podobnego jan@firmowy$ [email protected]
polecenia użyliśmy przy zabezpieczaniu pro- -D 8080
tokołów pocztowych.
Bardzo często nasz komputer domowy otwiera sesję na komputerze domowym,
nie ma stałego adresu IP i nie można mu wte- a opcja -D sprawia, że będzie on działał jako
dy przypisać nazwy DNS. W takiej sytuacji na- serwer pośredniczący (proxy) typu SOCKS
leży skorzystać z usługi dynamicznego DNS dynamicznie tworząc tunele do wybieranych
oferowanego np. przez serwis dyndns.org. Po- przez nas adresów. Jeszcze tylko musimy odlega ona na przypisaniu komputerowi o zmien- powiednio skonfigurować przeglądarkę ustanym adresie IP stałej nazwy DNS. Dzięki temu wiając proxy typu SOCKS i podając localhost
można nawiązać z nim połączenie SSH nawet jako adres serwera i port 8080 – taki sam jaki
jeśli nie wiemy jaki aktualnie ma adres. Sytu- został określony przy wywołaniu SSH. Takie
acja jest bardziej skomplikowana, gdy ani ser- ustawienia pozwalają na połączenie się z serwer projektowy ani nasz komputer domowy wisami, które zostały oficjalnie zablokowane
nie są osiągalne z Internetu. Możliwe jest wte- przez administratora sieci, dzięki tunelowaniu
dy użycie publicznie dostępnego serwera SSH, komunikacji przez komputer domowy.
np. jednego z serwisów oferujących bezpłatW wielu sieciach ograniczenia nakładane na
ne konta na maszynach uniksowych i linukso- ruch sieciowy są większe. Administratorzy uniewych [7]. Warto zwrócić uwagę na to czy regu- możliwiają połączenia przez SSH blokując port
lamin serwera nie zabrania używania go w ce- 22 na zaporze ogniowej (firewall). Pozostaje jelu zestawiania tuneli i proxy. W wielu serwi- dynie możliwość używania portów 80 (HTTP),
sach jest to zabronione, bo powoduje wzmożo- 443 (HTTPS) i 8080 (alternatywne HTTP). Nany ruch sieciowy.
leży wtedy serwer SSH skonfigurować tak, aby
Skoro wiemy już wiele na temat uzyski- pracował na jednym z trzech dozwolonych porwania dostępu do zabezpieczonej sieci za po- tów np. na 443. W tym celu dodajemy wpis
Port 443 do pliku konfiguracyjnego demona
OpenSSH /etc/ssh/sshd_config. Po zmianie trzeba pamiętać o restarcie usługi i można nawiązać
połączenie z komputera firmowego wpisując:
http://jakilinux.org/aplikacje/sztuczki-z-ssh/ – Artykuł o sztuczkach z SSH cz.1
http://jakilinux.org/aplikacje/sztuczki-z-ssh-2-tunele/ – Część druga artykułu.
http://www.openssh.com/ – strona projektu OpenSSH
http://winscp.net/ – WinSCP, klient SCP i SFTP dla systemów Windows
http://www.chiark.greenend.org.uk/~sgtatham/putty/ – Putty, klient SSH dla
systemów Windows
http://gftp.seul.org/ – GFTP, graficzny klient m.in. SFTP.
http://www.red-pill.eu/freeunix.shtml – lista darmowych kont SSH
http://fuse.sourceforge.net/sshfs.html – SSHFS
http://roumenpetrov.info/openssh/ – Rozszerzenie X.509 dla OpenSSH.
styczeń 2010
jan@firmowy$ [email protected]
-D 8080 -p 443
Nie zmieniając konfiguracji przeglądarki znów
mamy dostęp do zablokowanych serwisów.
Nie jest to jednak rozwiązanie w pełni satysfakcjonujące. Co prawda Firefox wspiera
obsługę proxy typu SOCKS, ale wiele programów tego nie potrafi. W takiej sytuacji pomoc-
Rozwiązania
Zabawa w SSHowanego
nym może okazać się program tsocks. Pozwala on korzystać z proxy SOCKS programom,
które nie wspierają konfiguracji z takim typem pośrednika. Dla aplikacji taki sposób połączenia jest przezroczysty, tak jakby łączył się
z siecią bezpośrednio. Instalujemy tscocks na
komputerze firmowym poprzez
jan@firmowy$ sudo aptitude install
tsocks
a następnie konfigurujemy w pliku /etc/
tsocks.conf jak na Listingu 3.
Parametr local określa, jakie adresy mają być traktowane jako lokalne. Oznacza to, że
proxy nie będzie stosowane do połączenia z nimi. Parametr server zawiera adres serwera pośredniczącego. W tym wypadku jest to lokalny
komputer firmowy czyli localhost (127.0.0.1).
Parametr server-port wskazuje, na którym
porcie nasłuchuje pośrednik, jest to ten sam
port co przy opcji -D polecenia ssh. Ostatni
z parametrów server_type to typ proxy, wpisujemy tu 4 lub 5. Po zapisaniu konfiguracji
możemy korzystać z dobrodziejstw jakie oferuje program. Polecenie:
Zabezpieczenia potrafią jednak być bardzo
uciążliwe nie tylko dla włamywaczy, ale i dla
użytkowników. Przyjmijmy, że na naszym serwerze obok istniejącej już witryny w PHP trzeba
uruchomić drugą stronę napisaną w Perlu. Zazwyczaj wymaga to zainstalowania wielu bibliotek Perla, a ich ręczne instalacja zajęłaby pół
dnia. Kilka godzin pracy polegającej na szukaniu modułów w repozytoriach, lub CPAN, pobieraniu ich, a następnie kopiowaniu na serwer
i instalowaniu jeden po drugim to perspektywa,
która może zniechęcić. Na szczęście SSH pozwala nam zaoszczędzić tego wysiłku. Na serwerze WWW jest już zainstalowane OpenSSH,
ale braknie pakietu tsocks. Pobierzemy go ręcznie z jednego z serwerów lustrzanych Debiana,
skopiujemy i zainstalujemy.
Jak widać na powyższym przykładzie dużo pracy jest z instalacją ręczną nawet jednego pakietu.
Po instalacji konfiguracja tsocks będzie
wyglądała tak samo jak na Listingu 3. Trzeba jeszcze tylko zestawić tunel odwrotny i uruchomić serwer pośredniczący. Zaczniemy od
ponownego zalogowania się na serwer WWW
jan@firmowy$ ssh jan@serwerfirmowy -R
jan@firmowy$ tsocks audacious
8022:localhost:22
powoduje, że tscocks uruchamia odtwarzacz muzyki Audacious. Wszystkie żądania sieciowe,
z wyjątkiem tych do adresów zdefiniowanych
w parametrze local, tak uruchomionego odtwarzacza będą obsługiwane przez tsocks i przesyłane przez proxy zbudowane w oparciu o SSH.
Teraz połączenia na port 8022 serwera będą przekierowywane do komputera firmowego. Polecenie:
Ucieczka
ze strefy zdemilitaryzowanej
wydane z serwera WWW połączy nas do komputera lokalnego. Dodatkowo ustawi proxy na
porcie 8080 za pośrednictwem którego będzie
można łączyć się z Internetem, tunelując ruch
przez komputer lokalny. Kolejnym krokiem
jest otwarcie drugiej sesji SSH i wykonanie jako root polecenia:
Mamy już wystarczająco dużo doświadczenia z SSH, aby przystąpić do bardziej zaawansowanego zadania. Pozwoli ono wykorzystać i utrwalić zdobytą do tej pory wiedzę. Przypuśćmy, że administrujemy firmowym serwerem WWW. Systemem operacyjnym komputera jest Debian i mamy do niego
dostęp przez SSH. Nikt nie będzie nam blokował dostępu do serwera, ale jak się często
zdarza maszyna została umieszczona w strefie zdemilitaryzowanej (DMZ). DMZ to podsieć, do której jest dostęp z sieci firmowej jak
i z Internetu, ale komputery w niej się znajdujące nie mogą nawiązywać połączeń na zewnątrz strefy. Jest to powszechna praktyka
bezpieczeństwa. Jeśli intruz przejąłby kontrolę nad serwerem znajdującym się w takiej
strefie to nie może się z niego połączyć do
komputerów pracowników firmy ani do Internetu, w celu np. rozsyłania SPAMu lub atakowania innych maszyn.
jan@serwerfirmowy$ ssh jan@localhost
-p 8022 -D 8080
jan@serwerfirmowy# tsocks aptitude
a następnie wybranie i zainstalowanie niezbędnych pakietów oprogramowania. Po zakończonej pracy zamykamy wszystkie sesje
SSH a tym samym tunele. Ponieważ tsocks zostało już zainstalowane i skonfigurowane, następnym razem w podobnej sytuacji będzie
można rozpocząć od zestawiania tuneli.
Trudno jest przecenić wartość SSH. Jest
ono czymś więcej niż tylko szyfrowanym następcą telnetu i rlogin. Pozwala na zdalne wykonywanie poleceń podobnie jak RSH, szyfrując kanał transmisji. Umożliwia kopiowanie plików przez SCP jako bezpieczna alternawww.lpmagazine.org
tywa dla RCP. Zastępuje FTP przez bezpieczny
protokół SFTP. Dzięki SSH możemy przekierować porty, tworzyć tunele i przekierowywać sesje X11 między różnymi komputerami w sieci.
Zastosowanie autoryzacji przez klucze pozwala na proste stosowanie SSH w skryptach, nie
wymagających interakcji użytkownika. Możemy również utworzyć pośrednika sieciowego,
który zostanie wykorzystany przez przeglądarkę WWW lub inne programy.
Rozwiązania bazujące na SSH
W tym rozdziale przedstawionych zostanie kilka
rozszerzeń i rozwiązań bazujących na SSH.
Bardzo wygodnym narzędziem dla wielu
użytkowników może okazać się SSHFS (SSH
File System). Pozwala on na zamontowanie
fragmentu systemu plików zdalnego serwera
na lokalnej maszynie i używanie go jako dodatkowy dysk. Rozwiązanie to wykorzystuje
połączenie SSH i FUSE, czyli system plików
w przestrzeni użytkownika.
Innym ciekawym rozwiązaniem wykorzystującym SSH jest protokół FISH. Został on
opracowany na potrzeby programu mc (Midnight Commander) do kopiowania plików za
pomocą zdalnych wywołań powłoki. Wspiera nie tylko SSH, ale również RSH. W praktyce jednak wykorzystuje ten pierwszy. Protokół, poza Midnight Commanderem, jest używany m.in. w popularnym menedżerze plików
KDE – Konquerorze.
W artykule została przedstawiona możliwość autoryzacji w SSH za pomocą klucza
kryptograficznego, ale warto również wiedzieć,
że zostało opracowane rozwiązanie pozwalające na logowanie za pomocą certyfikatów X509.
Certyfikaty, czyli bardziej zaawansowana wersja kluczy, oprócz samego materiału kryptograficznego zawierają informację o właścicielu
certyfikatu i ścieżce certyfikacji – organizacjach
odpowiedzialnych za jego wystawienie. Rozszerzenie jest rozwijane niezależnie od głównej
gałęzi projektu OpenSSH.
To jednak nie wszystko.Wachlarz pomysłów na wykorzystanie SSH jest bardzo szeroki
i zależy od inwencji i potrzeb użytkowników.
O autorze
Autor jest z wykształcenia inżynierem
elektroniki, Linuksem interesuje się od
ośmiu lat. Na co dzień używa go tak w
pracy, jak i w domu a jego ulubione dystrybucje to Gentoo i Debian.
Kontakt z autorem:
[email protected]
49