• Podstawy: część pierwsza zawiera wyjaśnienia podstawowych tematów związanych z najprostszym skonfigurowaniem ssh. Logowanie do shella odbywa się poprzez wpisanie hasła systemowego usera. Ponadto polecam notatkę o szyfrowanym sftp.
   
• Podstawy: część druga (jesteśmy na niej), to tłumaczenie z angielskiego na polski doskonałego artykułu o konfigurowaniu ssh autorstwa Vincenta Danena.
   
• VNC, czyli zdalne przejmowanie Pulpitu w szyfrowanym tunelu SSH.
   
• Uruchomienie programu wymagającego X-Window pod tunelem ssh (opcja X11Forwarding yes w sshd)

Na sąsiedniej stronie opisałem najbardziej prymitywny sposób logowania się za pomocą ssh - poprzez wysłanie w sieć hasła shellowego (bez użycia tzw. kluczy). Czas na lepsze rozwiązanie. Poniższy artykuł to perełka znaleziona w Internecie na stronie Mandrake. Niestety, napisana w języku angielskim może nie być dostępna dla wielu Polaków. Przetłumaczyłem ją na spółkę z córką i zachęcam do praktycznego zastosowania.

Wstęp od tłumacza (czyli ode mnie ;).

Logowanie za pomocą haseł jest uważane za mało bezpieczne, ponieważ ktoś może je podsłuchać i w konsekwencji przeprowadzić atak podszywania. Wskazane jest więc (na serwerze) wyłączyć tą możliwość (w pliku /etc/ssh/sshd_config wiersz PasswordAuthentication no) i nauczyć się tworzenia tzw. tunelu szyfrowanego opartego na kluczach. Metoda kluczy, czyli tzw. kryptografia publiczna polega na wygenerowaniu dwóch kluczy: publicznego (do szyfrowania danych) i prywatnego (do odszyfrowywania danych), które posiadają unikalną cechę - mimo, że nie są do siebie podobne, prowadzą do identycznego rozwiązania po użyciu algorytmów szyfrujących.

Autor artykułu Making the most of OpenSSH nie zajmował się rozwiązywaniem problemów konfiguracyjnych, przyjmując, że pisze dla znawców Linuksa. Dlatego proponuję pierw przeczytać stronę ssh1.php i skonfigurować połączenie ssh oparte na uwierzytelnianiu hasłem.

Oryginał (w wersji angielskiej) znajduje się na stronie
www.mandrakesecure.net/en/docs/openssh.php

Kopia wersji angielskiej jest także w moim archiwum.

*

"Making the most of OpenSSH" jest świetnym opracowaniem autorstwa Vincenta Danena opisujacym konfigurację OpenSSH. Tekst podzielono na 6 części, z których każda może być samodzielnym artykułem. Czytelnik dopiero poznający Linuksa powinien wiedzieć, że demona sshd oraz klienta ssh można zainstalować pobierając najnowsze paczki z domowej strony projektu http://www.openssh.com . Ponieważ firma MandrakeSoft nadzoruje aktualizację i informuje użytkowników o zauważonych błędach - polecam jej dystrybucję dla nowicjuszy. Dodatkowym atutem Mandrake jest automatyzacja procesów instalacyjnych i konfiguracyjnych OpenSSH, co skutkuje oddaniem produktu prawie gotowego do użycia.

*

Podczas opisu wydawanych poleceń możesz natknąć się na taki zapis:

$ ssh-add -d ~/.ssh/id_rsa
Znak dolara $ sygnalizuje, że polecenie jest wydane z pozycji zwykłego użytkownika (znak # symbolizuje roota).

Znak tyldy ~ jest skrótem ścieżki dostępu do katalogu domowego usera i w niniejszym opracowaniu oznacza /home/uzytkownik

*

Zacznę od... zacytowania fragmentu kończącego artykuł:
Powinno zostać jasno stwierdzone, że OpenSSH to duży, elastyczny i z całą pewnością niezbyt łatwy program. By wydobyć możliwie wiele z OpenSSH trzeba przekopać się przez sterty stron i plików konfiguracyjnych...

Mandrake Secure: Making the most of OpenSSH
Data utworzenia: 20 Sierpień 2002
Autor: Vincent Danen

• Dostęp bez hasła. Używanie publicznych/ prywatnych kluczy.
• Używanie tzw. Agentów SSH.
• X i szyfrowane połączenie na wskazanych portach.
• Bezpieczne SSH bez bezpośredniego nadzoru.
• Konfiguracja klienta SSH (najtrudniejszy punkt).
• Konfiguracja serwera sshd.

OpenSSH zastępuje stare, wysłużone i nieprzydatne w dzisiejszych czasach protokoły telnet czy rsh. Stał się standardem używanym do logownia na odległych komputerach obsługiwanych przez Linuksa, BSD i innych UNIXopodobnych systemach. Jest bazowany na ostatniej darmowej wersji oryginalnego SSH (wersja 1.2.12) dostępnego na licencji BSD. Ponieważ SSH stał się tzw. programem komercyjnym (for-profit), jego darmowa wersja OpenSSH (non-profit) szybko zyskała popularność jako w pełni funkcjonalne zastępstwo dla komercyjnego SSH.

OpenSSH został wprowadzony w Linuksie Mandrake począwszy od wersji Mdk_7.2 oraz jako część kompletu "crypto" od wersji Mdk_7.0. Mimo, że teoretycznie telnet i rsh są nadal dostępne, używanie tych protokołów jako narzędzi umożliwiających logowanie na odległym serwerze nie jest polecane. Używanie OpenSSH jest dużo lepszym pomysłem.

Jednym z problemów związanych z OpenSSH jest jego nadmierna złożoność. OpenSSH oferuje zbyt wiele opcji, zarówno po stronie klienta jak i dla serwera. Niestety czyni go to skomplikowanym w użyciu i jest przyczyną błędów w konfiguracji. OpenSSH mimo, że jest narzędziem bezpieczeństwa, ma niestety bardzo bogatą historię błędów w zabezpieczeniach. MandrakeSoft zanotował osiem wykrytych błędów związanych z bezpieczeństwem od października 2000 r. (do 20.08.2002). Czy czyni to używanie OpenSSH niepolecanym? Absolutnie nie. Możliwość zaistnienia dziury w bezpieczeństwie OpenSSH zawsze będzie możliwa (choćby ze względu na złożoność kodu), jednakże korzyści mocno przeważają nad wadami (i podobnymi protokołami do odległego logowania: telnetem, rsh). Używanie OpenSSH jest dużo bezpieczniejsze niż używanie np. telnetu.

Oczywiście, używanie OpenSSH (lub każdego z SSH) może być tak złożone lub tak proste jak sam zechcesz, by było. Spróbujemy sprawić, by używanie OpenSSH stało się proste, jednocześnie pozwalając Ci dobrać się do niektórych ze świetnych cech, jakie posiada.

Mimo, że niniejsza notatka jest nastawiona dla Linuksa Mandrake, robienie użytku z tych informacji na każdym systemie unixowym, obsługującym OpenSSH nie powinno być związane z praktycznie żadnymi odstępstwami od tego, co znajduje się tutaj (różne mogą być umiejscowienia plików i katalogów).

*

Dostęp bez hasła.
Używanie Publicznych/ Prywatnych Kluczy z OpenSSH

Jedną z najlepszych cech OpenSSH jest możliwość używania publicznie dostępnych kluczy, by zalogować się na odległy serwer. OpenSSH szyfruje całą komunikację, ale od chwili ustalenia połączenia. Nie jest wskazane wysyłanie hasła zanim nie nastąpi szyfrowanie połączenia. O wiele bezpieczniej jest użyć kluczy publicznych i dopiero potem ewentualnie uwierzytelnić się dodatkowo poprzez hasło.

Zaczynamy...

Załóżmy, że jesteś Jasiem. Masz swój komputer z kontem jasiu i administrujesz poprzez SSH odległy serwer Kazia. Serwer Kazia ma zainstalowany (poza sshd) serwer pocztowy obsługujący użytkownika jasiu osadzonego na shellowym koncie (dla naszej wygody konta na obu komputerach nazwaliśmy jasiu), z którego odbierasz swoją pocztę. Podczas gdy jesteś wystarczająco przebiegły, by za pomocą SSH chronić informacje, które wysyłasz (hasła, komendy używane podczas administracji itd.), jednocześnie używasz regularnego klienta POP3 by odbierać swoją pocztę POP3. Zapominasz, że komunikacja POP3 jest kompletnie widoczna: hasło POP3 zostanie wysłane bez żadnego zabezpieczenia, o treści przesyłki nie wspomnę. Z litości nad Tobą przyjmuję jednak, że nie tyle zapomniałeś, ile pragniesz ustawić serwer POP3 pracujący pod SSL w najbliższej przyszłości, a dotychczas po prostu nie miałeś na to czasu ;) . Niestety, póki co - wszystkie złośliwe, ciekawskie osoby mogą przy pomocy sniffingu (podsłuchiwania-obwąchiwania) dostać Twoje hasło POP3. Jako, że nie używasz żadnego oprogramowania wirtualnie hostującego pocztę, a konto POP3 jest połączone z Twoim shellowym kontem, praktycznie wysyłasz swoje informacje o logowaniu do sieci w sposób umożliwiający ich podglądanie. Atakujący może więc zwąchać Twój login oraz hasło shellowe po to, by otrzymać dostęp do systemu (prawdopodobnie w miarę możliwości przy pomocy telnetu).

To jest zły scenariusz. Jest na szczęście kilka prostych sposobów, by złagodzić problem.

• Pierwszym jest użycie systemu wirtualnie hostującego pocztę, który oddziela użytkowników poczty od użytkowników systemu. Dzięki temu użytkownicy poczty nie będą mieli konta shellowego.
• Drugim sposobem jest użycie szyfrowania w komunikacji POP3 poprzez wykorzystanie POP3 pracującego pod SSL.
• Ostatnią metodą jest użycie kluczy SSH i nią się teraz zajmiemy.

Powyższy scenariusz zmieni się na lepsze, gdy przyjmiemy, że administrator Kaziu skonfigurował serwer OpenSSH, tak by odrzucał autentykację hasłem. Wszyscy, którzy chcą połączyć się z serwerem muszą mieć ważny klucz do konta, na które chcą wejść. Czyli: NIE MA KLUCZA - NIE MA DOSTĘPU. Wyłączona autentykacja hasła oznacza, że nikt nie musi znać hasła shellowego. Jasiu może się zalogować na serwerze Kazia, ponieważ publiczny klucz Jasia został umieszczony na serwerze Kazia i istnieje pełna zgodność pary kluczy: publicznego (na serwerze Kazia) i prywatnego (na komputerze Jasia). W tym wypadku nikt nie ma szansy przechwycić nazwy użytkownika oraz hasła do shella, gdyż... nie używa się tych danych do logowania.

Zalety kluczy SSH są więc jasne i niepodważalne.

Proponuję, by pierwszym etapem nauki była obsługa SSH za pomocą kluczy, bez używania hasła shellowego. Musimy więc na komputerze-kliencie (po zainstalowaniu klienta ssh) wygenerować parę kluczy składającą się z klucza publicznego i prywatnego. Teoretycznie SSH obsługuje trzy typy kluczy: RSA1, RSA2 i DSA. Wskazane jest lekceważenie RSA1 (zarówno jako udostępniony protokół w OpenSSH i jako typ klucza), by zamiast tego skoncentrować się na używaniu RSA2 i DSA. Ja osobiście wolę klucze DSA. Różnicą pomiędzy kluczami RSA1 i RSA2 jest używany protokół SSH. Klucze RSA1 są używane z protokołem nr 1, a RSA2 (zwykle nazywane po prostu kluczami RSA) z protokołem nr 2. Klucze DSA mogą być używane jedynie z protokołem 2.

Aby wygenerować parę kluczy DSA, wykonaj jako użytkownik jasiu (na komputerze Jasia) zlecenie:

$ ssh-keygen -t dsa

Wykreujesz w ten sposób 1025 bitową parę kluczy DSA. Prywatny klucz zostanie utworzony na Twojej stacji, w pliku /home/jasiu/.ssh/id_dsa . Natomiast publiczny w tym samym katalogu, ale w pliku /home/jasiu/.ssh/id_dsa.pub (miejsce publicznych kluczy na odległym serwerze jest w pliku ~/.ssh/authorized_keys i do niego skopiujesz zawartość /home/jasiu/.ssh/id_dsa.pub).
Jeśli chcesz używać klucza RSA2, użyj komendę:
$ ssh-keygen -t rsa
a jeżeli upierasz się przy kluczu RSA1, wpisz:
$ ssh-keygen -t rsa1

Zostaniesz zapytany o tzw. przepustkę czyli passphraze (specjalnie jest to nazywane przepustką, a nie np. hasłem), by zabezpieczyć prywatny klucz. Przepustka może zawierać od 10 do 30 znaków, powinna być trudna do zgadnięcia, wskazane jest bezlitosne mieszanie liter, cyfr, interpunkcji i pustych spacji. Treść przepustki czyli passphraze zapisz na kartce i... ukryj w sejfie. Przepustka no i oczywiście prywatny klucz muszą być za wszelką cenę chronione. Plik z prywatnym kluczem powinien mieć restrykcyjne prawa dostępu (powrócę później do tego tematu).

Zmianę przepustki czyli passphraze wykonasz za pomocą tej komendy:

$ ssh-keygen -p -f /home/jasiu/.ssh/id_dsa

To zlecenie zmusza ssh-keygen, by zmienił przepustkę czyli passphraze do prywatnego klucza przechowywanego w pliku ~/.ssh/id_dsa (prywatny klucz DSA). Będziesz zapytany o starą przepustkę i o nową. Nie ma sposobu na odzyskanie treści przepustki, więc jeżeli kiedyś zapomnisz ją - będziesz musiał wygenerować nowy klucz, wykasować stary i rozprowadzić nowy publiczny klucz (~/.ssh/id_dsa.pub) po serwerach, na których chcesz go używać.

Upewnij się, że na odległym komputerze Kazia jest zainstalowany serwer sshd. Ponadto dopilnuj, aby Kaziu wprowadził właściwe wpisy do pliku /etc/hosts.allow no i... udostępnił serwer sshd dla świata poprzez firewalla.

Teraz, gdy pierwszy krok jest skończony, musisz skopiować zawartość publicznego klucza znajdującego się na Twojej stacji (w domowym katalogu, w pliku ~/.ssh/id_dsa.pub) i umieścić na odległym serwerze (tym na którym chcesz się zdalnie logować w przyszłości) do pliku ~/.ssh/authorized_keys (w nowym wierszu). Jak to zrobić? Teoretycznie są dwa sposoby.

• Pierwszy, nierozsądny - gdy na odległym serwerze ustawiona jest opcja autentykacji hasłem shellowym. Możesz w takich okolicznościach "na upartego" skopiować ze swojej stacji zawartość pliku ~/.ssh/id_dsa.pub do docelowego pliku ~/.ssh/authorized_keys (znajdującego się na koncie domowym odległego serwera), ale narażasz się na możliwość wykradzenia-zwąchania jego treści.
• W drugim przypadku musisz w bezpieczny sposób (np. pocztą lub SMS) wysłać publiczny klucz ~/.ssh/id_dsa.pub (pobrany z katalogu domowego ze swojej stacji) do administratora odległego serwera, by umieścił jego zawartość na Twoim koncie shellowym w pliku ~/.ssh/authorized_keys.

Sumując.
Docelowe miejsce publicznych kluczy jest w pliku ~/.ssh/authorized_keys na odległym serwerze. Na przykład, komputer A jest Twoim domowym komputerem, a komputer B jest Twoim systemem pracy, do którego chcesz mieć dostęp SSH. Prywatny klucz musi pozostawać na komputerze A (w pliku ~/.ssh/id_dsa), podczas gdy zawartość publicznego klucza z komputera A (~/.ssh/id_dsa.pub) powinna być skopiowana do ~/.ssh/authorized_keys na odległy komputer B. Opisywany plik /.ssh/authorized_keys może zawierać więcej niż jeden klucz, więc jeśli masz domowy system i laptopa, możesz wygenerować dwa oddzielne klucze, po jednym dla każdego urządzenia, przechowując oba publiczne klucze na serwerze, pozwalającym ci na połączenie bez hasła zarówno z domu, jak i z laptopa. Uwaga: wykonaj dwa oddzielne klucze, po jednym dla każdego urządzenia (to ważne).

Oczywistym jest, że jeśli używasz klucza protokołu 2, serwer musi popierać protokół 2. Nie powinno być z tym problemu, gdyż protokół 2 uznano za bezpieczniejszy niż protokół 1 i w związku z tym jest bardziej preferowany. Niektóre dystrybucje Linuksa mają unieszkodliwiony protokół 1, podczas gdy na Mandrake, w OpenSSH domyślnym wybieranym protokołem jest protokół 2, ale z możliwością cofnięcia się do protokołu 1.

Jeżeli chcesz skopiować jakiś plik za pomocą ssh, zostaniesz zapytany o przepustkę czyli passphraze lokalnie. Przepustka odblokuje prywatny klucz umożliwiający zalogowanie do odległego serwera bez wymieniania haseł w sieci.

Uwaga na koniec - nie ufaj nikomu.

Wyjaśnię to na przykładzie. Jeśli Jaś wysyła swój publiczny klucz (/home/jasiu/.ssh/id_dsa.pub) do Kazia (który jest administratorem odległego systemu), prosząc Kazia o wprowadzenie go do pliku ~/.ssh/authorized_keys (oczywiście na na serwerze Kazia, na koncie jasiu), Kaziu nie powinien zaufać samemu kluczowi, jeżeli Jaś nie dostarczy mu klucza fizycznie (np. na dyskietce, przez zaufaną osobę). Jeśli Jaś wyśle klucz e-mailem do Kazia, Kaziu musi założyć, że klucz jest nielegalny, jako że e-mail jest niebezpiecznym środkiem transportu. Przypuśćmy, że jednak w końcu udało się dostarczyć do Kazia klucz publiczny Jasia. Zależnie od poziomu paranoi Kazia można dalej sprawdzać i upewniać się co do autentyczności klucza. W takich okolicznościach Jasiu może zadzwonić do Kazia i powiedzieć mu jaki jest "odcisk palca klucza" (zaraz wyjaśnię co to takiego). Dylemat jest podobny do oznaczania kluczy w GnuPG i pojawia zawsze, gdy mamy do czynienia z sytuacją, gdy używana jest niebezpieczna metoda transportu publicznego klucza (najlepiej osobiście samolotem:). Kaziu podczas rozmowy telefonicznej może upewnić się, że osoba z drugiej strony słuchawki to Jasiu w prosty sposób: przy pomocy "odcisku palca klucza". Otrzymać go można poprzez wpisanie zlecenia:

$ ssh-add -l id_dsa.pub

Pokaże się tzw. "odcisk palca klucza" publicznego DSA Jasia.

$ ssh-add -l id_dsa.pub
1024 61:ed:d2:82:35:b4:54:3d:92:26:f8:48:69:21:de:c3 /home/joe/.ssh/id_dsa (DSA)

Kaziu może podobnie użyć tej samej komendy na kluczu, który Jaś twierdzi, że mu wysłał. Jeśli oba odciski palców się zgadzają, to oznacza, że osoba po drugiej stronie słuchawki ma ten sam klucz publiczny. Można więc pośrednio przyznać, że klucz jest prawidłowy i legalny.

To mniej więcej objaśnia jak używać publicznych/prywatnych kluczy w OpenSSH, prócz kluczy hostowych. Klucze hostowe są opisane w sekcji Server Configuration.

*

Używanie tzw. Agentów SSH.

Chociaż używanie kluczy jest korzystniejsze od używania haseł, istnieje szczególny minus. Ponieważ przepustka czyli passphraze powinna być długa i trudna do odgadnięcia, ponowne jej wklepywanie za każdym razem może być nieporęczne i po prostu zwyczajnie denerwujące. Aby tego uniknąć, OpenSSH proponuje użycie Agenta-SSH, który zapisze treść prywatnego klucza (np. ~/.ssh/id_dsa) do swojej pamięci. Uchroni to Ciebie przed koniecznością wklepywania przepustki czyli passphraze za każdym razem, gdy chcesz użyć klucza prywatnego.

Aby użyć Agenta-SSH, musisz go zwyczajnie odpalić:

$ ssh-agent

a później dodać tożsamość (identity) klucza do cache agenta:

$ ssh-add

następnie podaj:

[/home/jasiu/.ssh/id_dsa] [i jakisprostyzapisidentyfikujacy]

Uwaga: powyższe zlecenie ssh-add nie zadziała, jeśli wykonujesz go w xterm (wygeneruje się błąd informujący o braku połączenia z agentem). Jest to spowodowane techniką zabezpieczającą Agenta-SSH, którego dane wyjściowe opierają się na PID (numerze ID procesu) Agenta-SSH i ścieżce do pliku socket jaki używa Agent-SSH. Bez tej informacji, ssh-add nie wie, z którym agentem się połączyć, ani jak się z nim połączyć. Dlatego ssh-agent powinien być używany w powłoce shellowej. W Linuksie Mandrake, jeśli rozpoczynasz nową sesję X (okienka np. KDE), uaktywnij terminal i po prostu wpisz "ssh-add", a Twój klucz (np. ~/.ssh/id_dsa) zostanie dodany do właściwego Agenta-SSH, oczywiście pod warunkiem, że podasz odpowiednią przepustkę czyli passphraze. W razie problemów pamiętaj, że nowego shella możesz uruchomić klawiszami CTRL ALT F2 (F3, F4, F5 itd.).

Jeśli chcesz wykasować klucze z Agenta-SSH, zrobisz to za pomocą parametru -d (użycie "-D" wykasuje wszystkie klucze z agenta). Na przykład jeśli masz i klucz RSA (np. ~/.ssh/id_rsa) i DSA (np. ~/.ssh/id_dsa), a chcesz usunąć klucz RSA z agenta, użyj zlecenia:

$ ssh-add -d ~/.ssh/id_rsa

Jeśli chcesz wiedzieć, jakie tożsamości (identities) Agent-SSH już posiada, użyj opcji "-I" (duże i).

Istnieje bardzo poręczy (choć niebezpieczny) programik Keychain, umiejący załadować tożsamości (identities) Agenta-SSH na cały okres aktywności urządzenia. Obecnie, jeśli wylogujesz się z X, Twój Agent-SSH jest usuwany, a kiedy ponownie się zalogujesz, musisz znowu wpisać swą przepustkę czyli passphraze . Jest to bezpieczne, ale irytujące. Dzięki Keychain wpisujesz przepustkę czyli passphraze raz, po czym może być ona używana podczas wielu sesji X i nawet podczas consolowego logowania. Oczywiście jeśli system będzie restartowany lub Agent-SSH zostanie zabity - będziesz musiał ponownie wpisać swoją przepustkę czyli passphraze i uruchomić Keychain.

Keychain (współpracujący ze skryptem bash) jest bardzo łatwy do zainstalowania. Ściągnij paczkę tar Keychain, rozpakuj ją i zainstaluj do /usr/bin (pod rootem). Potem, u każdego użytkownika który chce używać Keychain, musi zostać odpowiednio wypełniony plik ~/.bashrc (nadaj mu właściwe prawa). Wpisz w nim następującą treść:

# .bashrc
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
/usr/bin/keychain -quiet ~/.ssh/id_dsa
. ~/.ssh-agent-${HOSTNAME}

Ostatnie dwie linijki są interesujace. Mówią narzędziu Keychain, by ładował klucz ~/.ssh/id_dsa bez komentarzy (zwykle Keychain jest gadatliwy i informuje o wielu sprawach np. czy odpaliłeś nowego agenta, czy dodano klucz czy nie). Jeśli chcesz mieć więcej niż jeden klucz, po prostu dopisz je w linii komend. Na przykład, użycie kluczy RSA1, DSA i RSA może być takowe:

/usr/bin/keychain -quiet ~/.ssh/identity ~/.ssh/id_dsa ~/.ssh/id_rsa

Następnym razem, gdy zalogujesz się do konsoli lub otworzysz xterm - Keychain także się odpali i załaduje wszystkie określone klucze do Twojego Agenta-SSH.

Jedna końcowa notka. Agenty SSH nie są zbyt bezpieczne, a już szczególnie we współpracy z Keychain. Powinny być używane na zaufanych maszynach, ponieważ ładują nasze prywatne klucze do pamięci cache, w sposób nieszyfrowany(!). Jeśli atakujący zechce otrzymać dostęp do Agenta-SSH, może wysłać własne żądanie do niego (dopóki agent nie zostanie zabity lub prywatne klucze zostaną z jego cache usunięte).

Jeśli używasz Agenta-SSH w pracy lub w innym niezaufanym (lub pół-zaufanym) środowisku, będziesz musiał pamiętać o konieczności usuwania swoich prywatnych kluczy z Agenta-SSH na noc lub jeśli opuścisz miejsce pracy np. na obiad. Przypominam, że użycie zlecenia $ ssh-add -D ~/.ssh/id_rsa usunie wszystkie klucze. Dodatkowym zagrożeniem jest sytuacja, gdy tożsamości (identities) nie ma w Agencie SSH. Wtedy Keychain wywoła ssh-add, które z kolei zapyta o Twoją przepustkę. Atakujący może próbować zgadnąć Twoją przepustkę czyli passphraze, otrzymując w ten podstępny sposób dostęp do Twojego prywatnego klucza. Wyczyszczenie Agenta-SSH jest bardzo polecanym krokiem, ale zabicie go, zamyknięcie terminala, a nawet całkowite wylogowanie jest najlepszym środkiem chronienia swoich prywatnych kluczy.

*

X i Port Forwarding.

Prawdopodobnie jedną z najczęściej używanych cech w SSH jest możliwość kreowania bezpiecznych tuneli dla niebezpiecznych transportów. Na przykład, wszyscy wiemy, że POP3 jest niebezpiecznym protokołem. Jeśli masz shellowy dostęp do serwera POP3 (z którego pobierasz pocztę), możesz użyć tunelu SSH by przerzucić swoje dane POP3 z odległego serwera na komputer lokalny. Tak samo jest z aplikacjami X, możesz utworzyć tunel SSH do odległego serwera, odpalić aplikację GUI (okienka) na odległym systemie i mieć ją otwartą na lokalnym monitorze. Przyznasz, że ta cecha SSH jest niesamowicie potężna, gdyż pozwala Ci użyć niebezpiecznych protokołów w bezpieczny sposób (bez otwierania dodatkowych portów na ścianie ogniowej lub rozluźniania pozwoleń dostępu czy używania nieszyfrowanej komunikacji, żeby utworzyć połączenie lub uruchomić aplikację).

Przyjmijmy na chwilę, że chcesz uzyskać połączenie z odległym serwerem POP3 używając SSH. Może to zostać wykonane jedynie, jeżeli masz dostęp SSH do odległego serwera POP3. Pierwszym krokiem jest wybranie lokalnego portu pomiędzy 1024 a 65535; są to numery portów z którymi nieuprzywilejowani (unprivileged) użytkownicy mogą się związać. Na przykład, wybierz port 10110. Wykreuj tunel SSH tak:

$ ssh -L10110:localhost:110 odleglyserwer

Utworzy to tunel, który połączy port 10110 na komputerze lokalnym z portem 110 na odległym serwerze. Dzięki temu zostanie nawiązane szyfrowane połączenie SSH z odległym serwerem. Używając narzędzia netstat możesz zauważyć, jaki port jest otwarty i nasłuchujący:

[user@mdkhost user]$ netstat -l --tcp -p|grep ssh
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 *:ssh *:* LISTEN -
tcp 0 0 localhost.localdo:10110 *:* LISTEN 31295/ssh
[user@mdkhost user]$

tłumaczenie tekstu w powyższym nawiasie: (Nie wszystkie procesy mogły zostać zidentyfikowane, niektóre własne informacje o procesach nie zostaną pokazane, musisz być root'em aby zobaczyć wszystkie.)

Jeśli wyjdziesz z powłoki shellowej SSH, połączenie (forwarding) także zostanie zamknięte. Zanim wyjdziesz z shella, możesz sprawić, by Twój klient otrzymał pocztę POP3 (nie poprzez standardowe połączenie z odległym systemem na porcie 110, ale poprzez połączenie z lokalnym hostem:10110). Niestety, wynikają w tym miejscu małe komplikacje. Na przykład, jeśli chcesz użyć crona by odbierać pocztę poprzez fetchmail lub podobny program, możesz mieć szczególne wymagania związane z czasem trwania tunelowanego połączenia SSH i otwartych portów. Są dwie możliwości:

• wytrwałe połączenie (forwarding)

• tymczasowe połączenie (forwarding). Tutaj otwierasz tunel na krótki czas, ale wystarczający, by pocztowy klient (lub program odbierający) mógł połączyć się z odległym hostem. Uzyskasz to zleceniem:

  $ ssh -f -L10110:localhost:110 remotesystem sleep 10

  Mówi to SSH, aby przeszedł w tzw. tło (-f), otworzył połączenie tunelowane i wykonał komendę "sleep 10". Standardowo, po wykonaniu tej komendy SSH zakończy sesję. Jednak jeśli fetchmail zadziała w czasie owych 10 sekund, SSH zaczeka z przerwaniem połączenia i pozwoli na dokończenie pracy. Zapewni to utrzymanie tunelowanego połączenia w okresie, gdy Twój fetchmail pracuje (ale nie pozostawia go otwartego przez zbędny okres czasu).

Z drugiej strony, jeśli sprawdzasz pocztę co kilka minut, przemyśl możliwość pozostawienia połączenia bezustannie otwartego. Zrobisz to wpisując w komendzie sleep większą ilość czasu, jak np. 100000 (sekund). Możesz nawet wykazać się pomysłowością i na odległym systemie utworzyć mały skrypt, który co chwilę będzie wpisywał komendę sleep z niesamowicie dużymi wartościami. Ochroni Cię to przed ręcznym otwieraniem i zamykaniem połączeń.

Forwarding danych dla X11 działa na tej samej zasadzie. Domyślnie, Linux-Mandrake popiera forwarding X11 poprzez plik konfiguracyjny klienta (/etc/ssh/ssh_config). ForwardX11 jest tam ustawiony na "yes" dla wszystkich hostów. W pliku konfiguracyjnym serwera sshd (/etc/ssh/sshd_config), X11Forwarding także wskazuje na "yes".

Kiedy tunelujesz poprzez SSH do odległego serwera, możesz odpalać programy X11 w linii komend (zupełnie tak samo, jak byś zrobił, gdybyś używał xterm na lokalnym systemie). Na lokalnym systemie, zmienna DISPLAY jest używana, by powiedzieć programom X11 dokąd biec i może być ustawiona jako ":0". Na odległym systemie, podczas połączenia przez SSH, wartość DISPLAY będzie czymś w rodzaju "localhost:11.0". Mamy kilka sposobów odpalenia programów X11. Jednak najczęściej używane jest tunelowanie połączenia poprzez SSH i wykonanie komendy jak ta:

[user@mdkhost user]$ ssh antek@ pd124.wroclaw.sdi.tpnet.pl
[user@remotesystem user]$ gkrellm &

Otrzymamy przez to połączenie z odległym serwerem pd124.wroclaw.sdi.tpnet.pl jako użytkownik "antek" i umożliwimy użycie gkrellm (narzędzia do graficznego monitorowania). Zwróć uwagę na znak "&" w końcu linii komendy. Wskazuje on, że gkrellm powinien zapoczątkować pracę jako zadanie. Powinieneś w sumie pominąć znak "&" i po prostu utrzymać gkrellm powiązany z terminalem, minimalizując po prostu terminal na pulpicie. Wykonaj więc:

[user@mdkhost user]$ ssh -f user@remotesystem gkrellm

Robiąc tak, możesz bez obaw zamknąć xterm używany początkowo do nawiązania połączenia tunelowanego poprzez SSH. Pozostawisz w ten sposób gkrellm na pulpicie, jako niezwiązany z żadną sesją (ponieważ SSH jest w tle). Jeśli chcesz zamknąć połączenie, zabij program dla którego go nawiązałeś (czyli program gkrellm). Kiedy zamykasz gkrellm - połączenie poprzez też SSH zostanie przerywane.

*

Bezpieczne SSH bez bezpośredniego nadzoru.

Zdarzy się, że zechcesz uruchomić SSH, ale z różnych przyczyn nie będziesz mógł użyć przepustki czyli passphraze (np. gdy uaktywnisz połączenie przy pomocy crona). Przyjmijmy, że chcesz włączyć tworzenie backupów (kopii bezpieczeństwa) z odległego serwera do Twojej stacji, każdej nocy używając rsync w tulelu SSH. Utwórz na Twojej stacji jakiegoś prostego w nazwie użytkownika np. "backup" lub "mirror". Wykreuj dla niego klucze SSH z pustą (!) przepustką czyli passphraze (zwróć uwagę, że nie jest to typowe rozwiązanie). Skopiuj zawartość publicznego klucza znajdującego się na Twojej stacji (w domowym katalogu, w pliku ~/.ssh/id_dsa.pub) i umieścić na odległym serwerze (tym na którym chcesz się zdalnie logować w przyszłości) do pliku ~/.ssh/authorized_keys. Zależnie od tego, co chcesz backupować (zrobić kopie plików), możesz dodać klucz tego użytkownika nawet do pliku na koncie root'a ~/.ssh/authorized_keys. Uważaj, gdyż daje to użytkownikowi natychmiastowy i bezhasłowy (!) dostęp do odległego konta root'a lub do odległego systemu! Może to być bardzo poważną dziurą w zabezpieczeniach, jeśli nie skonfigurujesz wszystkiego prawidłowo.

Teraz, gdy użytkownik "backup" ma dostęp do odległego konta root'a, możesz napisać skrypt shellowy (patrz poniżej) i odpowiedni wpis w /etc/crontab (który go będzie odpalał), by włączyć tworzenie backupów. Zrobisz to, uruchamiając poniższy skrypt na swoim komputerze (jako użytkownik np. "backup"):

#!/bin/sh
RSYNC="/usr/bin/rsync -aP --quiet --delete -l -t -e ssh"
cd /data/backup/host
$RSYNC root@host:/etc .
$RSYNC root@host:/home .
...

Skrypt może być wykonany np. każdej nocy przez użytkownika "backup". Będzie działał prawidłowo, ponieważ nie ma zdefiniowanej przepustki czyli passphraze dla prywatnego klucza użytkownika, a publiczny klucz jest u odległego roota, w pliku /root/.ssh/authorized_keys.

Czas na zabezpieczenie konta użytkownika "backup" na Twoim komputerze. Pierwszym krokiem jest zmodyfikowanie pliku /etc/ssh/sshd_config i dodanie do niego:

DenyUsers backup

To powstrzyma wszystkich przed próbą zalogowania się na koncie "backup" poprzez SSH. Następnie, wyedytuj na swojej stacji plik /etc/passwd. Tutaj usuniemy możliwość zalogowania się użytkownika "backup" do systemu przez konsolę. By to zrobić, uruchom (na swoim komputerze) program vipw jako root. Przyjmując, że nazwa użytkownika brzmi "backup", wpisz poniższy tekst:

backup:x:512:512:Backup User:/home/backup:/bin/bash

Drugie pole, czyli "x", reprezentuje cień hasła (shadow password). Jednak możemy zmienić "x" na "*" które zabroni logowania na to konto. Ta linijka więc mogłaby po wyedytowaniu wyglądać tak:

backup:*:512:512:Backup User:/home/backup:/bin/bash

Domyślnie, vipw używa edytora tekstów vi. Jeśli nie znasz vi, to przynajmniej musisz znać te podstawowe: naciśnij znak "i" by dostać się do opcji INSERT. Pozwoli Ci to zmienić pole hasła. Kiedy już je zmienisz, naciśnij ESC by wrócić do trybu komend, potem wpisz "wq" by wyjść i zapisać zmiany. Kiedy skończysz, vipw zapyta, czy chcesz wyedytować także plik /etc/shadow. Wciśnij "no", gdyż nadal chcemy, aby to konto miało prawdziwe hasło.

Obecnie mamy następujący układ:

• Konto użytkownika "backup" (na lokalnej stacji) posiada swoje hasło, ale nikt nie może zalogować się na niego z odległego komputera (np. przez SSH), ani mając bezpośredni kontakt (w linii komend).

• Pozostała rezerwowa furtka, czyli możliwość użycia zlecenia su, za pomocą którego zalogowani użytkownicy nie będący root'ami będą mogli wpisać hasło shelowe użytkownika "backup", by zmienić się na użytkownika "backup". Dlatego zresztą zostawiłeś cień hasła (shadow password). Jeśli w swoim lokalnym systemie jesteś zalogowany jako root - nie musisz nawet się martwić o zapamiętanie hasła (gdyż możesz wówczas wykonać su do "backup" jako root, bez znania hasła użytkownika;)

Na koniec wspomnę o znanym już Ci programie Keychain. Możesz z nim robić swoje backupy zwykłym użytkownikiem, z przepustkowo chronioną parą kluczy. Aby to robić za pośrednictwem cronu wypisz wcześniej przepustkę czyli passphraze conajmniej raz, zanim Twoje prace poprzez cron zaczną działać.

O crontabie możesz poczytać tutaj.

*

Konfiguracja klienta SSH.

Ta część jest chyba najtrudniejsza i wymaga od administratora dużej wiedzy. Umożliwia wykwintną konfigurację połączenia, ale źle wykonana rażąco obniży bezpieczeństwo systemu.

Konfiguracja wychodzących połączeń SSH.

Konfiguracja klienta SSH składa się z trzech plików:

• /etc/ssh/ssh_config, który zajmuje się ogólnymi (na cały system) ustawieniami
• ~/.ssh/config, czyli konfiguracja prywatna użytkownika
• ~/.ssh/authorized_keys, który nadzoruje przychodzące połączenia (to do niego jak pamiętasz administrator Kaziu wprowadził dane z klucza Jasia ~/.ssh/id_dsa.pub.

Linux Mandrake standardowo załatwia konfigurację SSH (ze strony klienta) w części umożliwiającej używanie X11 poprzez wpis:

Host *
ForwardX11 yes
Protocol 2,1
StrictHostKeyChecking no

Strona man ssh_config(5) opisuje każdą opcję i tam ewentualnie poczytaj sobie o szczegółach. Tutaj w gruncie rzeczy wystarczy nam, by SSH umożliwił uruchomienie przekazywania (forwarding) X11, używał protokołu 2 (ewentualnie wrócił do protokołu 1, jeśli protokół 2 na odległym serwerze nie jest wspierany) i wyłączył ścisłe sprawdzanie kluczy (hostkey) w każdym połączeniu z odległym serwerem. Jest to dość liberalne, ale nadal względnie bezpieczne. Przecież z StrictHostKeyChecking ustawionym na "no" nadal będziesz ostrzegany o niedopasowanych kluczach podczas prób łączenia z serwerem (w przypadku różnic pomiędzy kluczem hosta zdefiniowanym w Twoim pliku ~/.ssh/known_hosts, a tym zaprezentowanym). Jeżeli jesteś paranoikiem, możesz zmienić wartość z "no" na "ask" (pytaj).

Uwaga: domyślna konfiguracja nie pozwoli Ci na tzw. przekazywanie połączenia z pomocą ForwardAgenta. Na przykład, jeśli siedzisz przy Komputerze A (masz tam domyślnie wyłączonego ForwardAgenta) i łączysz się z Komputerem B (który ma kopię Twojego klucza publicznego (~/.ssh/id_dsa.pub w pliku ~/.ssh/authorized_keys), nie musisz określać swojego hasła na Komputerze B. Ale jeżeli potem zdecydujesz się utworzyć tunel SSH (ponownie w roli czynności występuje SSH!) do Komputera C (z Komputera B), będziesz musiał wpisać hasło na Komputerze C, jeśli ForwardAgent jest niedostępny na Komputerze A i to mimo, że Komputer C zawiera Twój publiczny klucz. Przy udostępnionym ForwardAgent, możesz po prostu przeskakiwać do Komputera C bez wpisywania hasła. Jest to wygodna cecha, która niestety nie jest udostępniana domyślnie.

Zanim zacznę opisywać pliki konfiguracyjne SSH, pragnę zaznaczyć, że istnieje odrębna komenda preferencji z opcjami określonymi przez SSH, ale nie bedę teraz się tym zajmował (zainteresowanych odsyłam do man ssh_config(5)).

Plik /etc/ssh/ssh_config

Pozostawienie pliku /etc/ssh/ssh_config takim, jaki jest, będzie prawdopodobnie dobrym pomysłem, ponieważ możesz określać opcje w linii komend, w pliku konfiguracyjnym użytkownika (~/.ssh/config) i w systemowym pliku konfiguracyjnym. Dla ciekawskich opiszę jednak trochę plik /etc/ssh/ssh_config:

Host [host]
options
...

Host [host2]
options
...

Plik ten jest czytany od góry do dołu w komendzie "first match wins". Podczas kreowania pliku konfiguracyjnego upewnij się, że bardziej specyficzne wejścia są na liście pierwszymi, a domenowa dzika karta (wildcard) czyli np. domeny z *, ? (np. po*polska) lub globalne wejścia Hostów zdefiniowane są na końcu.

Kolejność pierszeństwa w odczytywaniu konfiguracji podczas startu SSH:

• Najwyższe pierwszeństwo danych ustawień jest wpisane na linii komend
• potem w lokalnym pliku konfiguracyjnym użytkownika
• a potem w pliku konfiguracyjnym systemu.

/home/antek/.ssh/config

Przykład wpisu do pliku ~/.ssh/config:

Host devel
HostName myserver.mydomain.com
User antek

Host otherserver.mydomain.com
User admin
ForwardAgent no
Port 220
ForwardX11 no

Host *.mydomain.com
ForwardAgent yes
Compression yes

Są tutaj zdefiniowane:

• w pierwszej grupie wpisów: "devel" Hosta, który zawiera pełną nazwę Hosta: myserver.mydomain.com. Takie dodanie aliasu podczas logowywania pozwoli Ci na używanie wywołania poprzez wpis "ssh devel" zamiast "ssh myserver.mydomain.com" . Ponieważ zdefiniowaliśmy domyślnego użytkownika "antek", używanie "ssh devel" jest równoznaczne z używaniem "ssh antek@myserver.mydomain.com". Trochę mniej do wklepywania:).

• Druga grupa wpisów definiuje Hosta z adresem otherserver.mydomain.com. Uwaga: jest to FQDN dla hosta, a nie alias(!). Określa ponadto domyślnego użytkownika ("admin"), u którego AgentForwarding ma być wyłączony, którego połączenia mają domyślnie wychodzić z portu 220 i którego tunelowanie połączenia SSH dla X11 jest uniemożliwione.

• Trzecia grupa wpisów definiuje domenową dziką kartę (wildcard) "*.mydomain.com". Sprawia to, że AgentForwarding jest dozwolony oraz że domyślnie udostępniamy kompresję.

Teraz możemy ustalić jakie cechy będą dostępne dla każdego hosta. Pamiętaj, że używamy domyślnego pliku konfiguracyjnego Linuksa Mandrake /etc/ssh/ssh_config, więc mamy także zdefiniowane opcje, które działają dla wszystkich hostów. Następująca tabela pokazuje jakie opcje będą dostępne podczas łączenia z myserver.mydomain.com, otherserver.mydomain.com, myhost.mydomain.com i otherhost.otherdomain.com.

Patrząc na tabelę, możesz przeoczyć pewną ciekawą regułę. ForwardAgent jest wobec jednych udostępniony, a wobec innych nie. Dlaczego? Przyczyną jest wpis w grupie *.mydomain.com (udostępniliśmy ForwardAgent i Compression dla wszystkich hostów, które pasują do domenowej dzikiej karty (wildcard)). Zauważ, że *.mydomain.com zawiera hosta myserver.mydomain.com. Innymi słowy, oprócz swoich standardowych opcji myserver.mydomain.com także ma udostępnione ForwardAgent i Compression (wraz ze zdefiniowanym użytkownikiem "antek" i z aliasem "devel").

Z drugiej strony grupa wpisów otherserver.mydomain.com, neguje definicję ForwardX11 oraz definicję ForwardAgent dla grupy wpisów *.mydomain.com. Tak więc, tunelowe połączenie SSH do otherserver.mydomain.com uniedostępni ForwardAgent i ForwardX11, choć są one udostępnione gdzie indziej. Użyje także Portu 220 domyślnie, z domyślnym użytkownikiem "admin". Jednakże, ponieważ Compression jest udostępniona dla *.mydomain.com, będzie udostępniona także dla tego hosta.

W końcu, podczas łączenia z otherhost.otherserver.com, jedynie ForwardX11 będzie udostępniony, ponieważ jest zrobione tak w głównej grupie wpisów. Jako że nie ma innej definicji która pasuje do hosta otherhost.otherdomain.com, jedynie te opcje określone jgłównej grupie wpisów będą zastosowane.

Jak widzisz, konfiguracja od strony klienta może być elastyczna i pozwala oszczędzić trochę czasu podczas użytkowania SSH. Jeśli rutynowo łączysz się poprzez SSH do odległego systemu z inną nazwą użytkownika niż aktualną na Twoim lokalnym pudle (np. użytkownik X na odległym systemie, użytkownik Y na lokalnym), możesz zdefiniować grupę głównych wpisów. W ten sposób wystarczy, że podczas próby nawiązania połączenia wpiszesz "ssh remotehost" zamiast wklepywać "ssh user@remotehost". Pamiętaj, że domyślnie, jeśli określisz jedynie nazwę hosta w linii komend (np. "ssh remotehost"), a ominiesz definiowanie nazwy konta, to SSH wykona logowanie na odległym koncie serwerowym pobierając nazwę użytkownika klienta.

Tak więc mamy za sobą konfigurację wychodzących połączeń SSH. A co z przychodzącymi?

Możesz także skonfigurować sposób, w jaki SSH będzie radził sobie z połączeniami przychodzącymi na Twoje konto. Jest jednak kilka ograniczeń co do konfigurowania rzeczy w ten sposób:

• Po pierwsze, wytyczne konfiguracji nigdy nie unieważnią ogólnoserwerowej konfiguracji. Na przykład: możesz zwiększyć bezczynny timeout serwera, ale nie możesz udostępnić poświadczenia hasła, jeśli ogólnoserwerowa konfiguracja na to nie pozwala.
• Jest bardzo polecane, abyś używał poświadczenia publicznego klucza jako jak najbardziej elastycznego. Po wybraniu poświadczenia hasłem, wiele opcji będzie dla Ciebie niedostępnych.

Konfiguracja klienta od strony serwera (czyli połączeń przychodzących na Twój komputer od odległego serwera) jest realizowana poprzez publiczne klucze (zarówno dla Protokołu 1, jak i 2). Przykładowo poprzez plik ~/.ssh/authorized_keys , którego wygląd będzie np. taki:

ssh-dss AAAAB3NxaC1kc3M...mc= user@somehost.com

Powyższy klucz został skrócony, ale możesz zauważyć, że każda linia w pliku ma następującą budowę:

• ciąg znaków: "ssh-dss"
• publiczny klucz (DSA lub RSA)
• na końcu adres właściciela; zwykle nazwa użytkownika i nazwa odległego hosta (przypominam, że teraz opisujemy konfigurację połączeń przychodzących SSH).

Ponadto możemy w pliku ~/.ssh/authorized_keys umieścić konfigurację kilku opcji. Wróćmy na chwilę do naszego scenariusza z użytkownikiem Jasiu robiącym kopie (backup) na serwerze Kazia. Tyle, że teraz jesteś Kaziem, który na swoim serwerze SSH konfiguruje połączenia przychodzące od stacji Jasia. Jasiu jest w stanie użyć komendę rsync na serwerze Kazia, po to aby stworzyć backup. Jako administrator, Ty, czyli tym razem Kaziu, możesz ograniczyć uprawnienia odległego Jasia, np. listę czynności, jakie użytkownik Jasiu może zrobić (jako root) na serwerze Kazia. Wykonasz to poprzez dodanie wpisu przed kluczem publicznym Jasia (w pliku authorized_keys , na koncie roota, oczywiście na serwerze Kazia):

command="/usr/bin/rsync" ...key...

Od teraz, jeśli odległy użytkownik Jasiu spróbuje połączyć się z serwerem Kazia i wykonać logowanie na shellu, wykona jedynie program /usr/bin/rsync. Niestety, można przydzielić jedynie jedną przymusową komendę na dany klucz (nie zadziała w tym przypadku nawet próba odpalenia "/usr/bin/rsync --help"), toteż jeśli chcesz, by odległy użytkownik był w stanie zrobić coś innego, musisz użyć kilku kluczy lub napisać skrypt.

Proponowany przeze mnie wrapper-skrypt jest prosty i mógłby być prawdopodobnie rozwinięty, ale na obecne potrzeby ilustruje wystarczająco to, co jest wymagane. Utwórz plik-skrypt /root/remote-rsync i wpisz jego ścieżkę dostepu do pliku authorized_keys.

Wygląd pliku authorized_keys :

command="/root/remote-rsync" ...key...

Jak widzisz, powyższy wpis umieszczony w pliku authorized_keys odpali plik-scrypt /root/remote-rsync , który z kolei powinien wygladać tak:

#!/bin/sh
if echo $SSH_ORIGINAL_COMMAND|grep -e "^rsync " >/dev/null 2>&1; then
$SSH_ORIGINAL_COMMAND
else
echo "No access. Sorry."
fi

Jeżeli komenda wydana przez odległego klienta NIE ZACZYNA SIĘ od "rsync", to echujesz "Spadaj gościu. Pa!" (brak dostępu, chyba coś kombinujesz) i zamykasz połączenie.

Scrypt sprawdza, czy "rsync[spacja]" jest pierwszą rzeczą w linii komend. Odrzuci więc "/usr/bin/rsync" i inne warianty. Upewnij się że dane uzyskane po grep doprowadzisz do /dev/null, gdyż w przeciwnym razie rsync pomyśli, że jest jakiś problem i nie wykona aktualnego transferu.

Widzimy tam też zmienną środowiskową $SSH_ORIGINAL_COMMAND. Ta zmienna zawiera w rzeczywistości linię komend, której zażąda klient od serwera będąc odległym użytkownikiem. (...)

Niestety, rsync, może pozwolić potencjalnemu atakującemu otrzymać kopie ważnych plików, choć nie będzie w stanie zrobić nic jako użytkownik root. Jednakże pamiętaj, że wiele programów (większość edytorów tekstów i klientów poczty pracujących w linni komend) pozwala na ucieczkę do shella. Jeśli używasz jednej z tych komend (lub programów jako przymusowej komendy) końcowy użytkownik może łatwo "uwolnić się" z przymusowej komendy.

*

Inna komenda, o której chcę wspomnieć to komenda "from", która pozwoli określić klucz (uprawniający do wejścia na konto) i hosta, z którego połączenie mogłoby być ustalone. Tak więc, jeśli klucz pasuje, ale pukający do drzwi serwera host nie, to połączenie zostanie odrzucone. By tego dokonać, umieść w swoim pliku authorized_keys wpis:

from="client.mydomain.com" ...key...

Możesz użyć FQDN, adresu IP lub domenowej dzikiej-karty(wildcards). A więc, zamiast ograniczania się do jednego hosta, możesz ograniczyć się do jednej domeny poprzez użycie "*.mydomain.com". Także możesz określić wiele nazw hosta, adresów IP i wyrażeń poprzez oddzielenie ich za pomocą przecinków. Możesz także użyć znaku "!" jako wyrażenie negujące. Na przykład wpis:

from="*.mydomain.com,!xclient.mydomain.com" ...key...

...pozwoli dostać się poprzez użycie określonego klucza, z każdego konta w mydomain.com, ale oprócz konta xclient.mydomain.com. Zapamiętaj jednak, że konfiguracja na cały serwer unieważni powyższy wpis (jeśli system jest ustawiony na odrzucanie wszystkich użytkowników z mydomain.com, to nawet użycie opisanej powyżej komendy nie wpuści ich).

Możesz także ustawić zmienne środowiskowe w taki sam sposób, używając:

environment="EDITOR=jasiu" ...key...

W powyższym przykładzie każdy łączący się z kontem określonym kluczem ma swoją zmienną środowiskową $EDITOR ustawioną na "jasiu". Możesz ustawić każdą zmienną środowiskową w taki sposób, a nawet wiele zmiennych poprzez wpis:

environment="EDITOR=jasiu", environment="MYVAR=somevalue" ...key...

Inną opcja jest ustawienie bezczynnego timeout dla klucza, w ten sposób:

idle-timeout=60s ...key...

W tym wypadku, timeout jest ustawiony na 60 sekund dla wszystkich połączeń z tym kontem, używających określonego klucza.

Na koniec, możesz także zabronić udostępniania port-forwarding, agent-forwarding i przydział tty na podstawie klucz-przez-klucz (key-by-key). Słowa kluczowe w takich okolicznościach to: "no-port-forwarding", "no-agent-forwarding" i "no-pty".

Na koniec ciekawostka. Poniższa komenda została rozbita na pół. Oryginalnie powinna być wpisana w jednym wierszu.

no-agent-forwarding,environment=
"MYVAR=somevalue",command="/usr/bin/env|/bin/grep MYVAR" ..key..

Powyższy wpis zapewni rozłączenie po wydaniu nieuprawnionego zlecenia listowania: ssh someuser@somehost /bin/ls

[user@mdkhost user]$ ssh someuser@somehost /bin/ls
MYVAR=somevalue
[user@mdkhost user]$ ssh someuser@somehost
MYVAR=somevalue
Connection to somehost closed.
[user@mdkhost user]$

Jak widzisz, usiłowano uzyskać listę katalogu domowego jakiegoś użytkownika someuser. Zamiast tego, wyświetliły się nam dane komendy grep. Podobnie, przy drugim podejściu, kiedy chciano uzyskać dostęp do shella - wyświetliły się dane komendy grep i połączenie zostało zamknięte. To w uproszczeniu ilustruje, jakie efekty może dać układanie komend. Zmienna środowiskowa $MYVAR została wykreowana na początku i nasze wezwanie do programu env uniedostepniło ją, podczas gdy grep oddzielił ją od reszty.

Powinno być dość jasnym, że jest wiele sposobów na skonfigurowanie OpenSSH. Niektóre z opcji, jeśli są używane bez dokładnego przemyślenia, są niebezpieczne.

*

Konfiguracja serwera.

W końcu opiszę konfigurowanie serwera OpenSSH. Jest to prawdopodobnie najprostsza część tego wszystkiego :) . Całość konfiguracji serwera OpenSSH jest zawarta w pliku konfiguracyjnym /etc/ssh/sshd_config. Pamiętaj, by po każdej zmianie konfiguracji restartować sshd! Domyślnie, sshd_config na Linuksie Mandrake wygląda tak (wszystkie komentarze usunięto):

Port 22
Protocol 2,1
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PAMAuthenticationViaKbdInt no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
KeepAlive yes
UsePrivilegeSeparation yes
Compression yes
Subsystem sftp /usr/lib/ssh/sftp-server

Konfiguracja zaczyna się od poleceń narzucających serwerowi SSH, aby nasłuchiwał na porcie 22, używał Protokołu 2 lub wrócił do Protokołu 1 jeśli klient nie popiera Protokołu 2. W celu podniesienia bezpieczeństwa można uznać tylko Protocol 2 i wówczas wpis będzie wyglądał tak: Protocol 2

Następnie definiuje trzy klucze hostów: SSH1 (RSA), następnie SSH2 (RSA) i SSH2 (DSA). Inne opcje określono w manpage sshd_config(5).

Słowo kluczowe PermitRootLogin określa, czy root będzie mógł logować się przez SSH. Prawdopodobnie lepiej jest zabronić bezpośredniego logowania na roota (i używać zlecenia sudo lub su przez nieuprzywilejowanego użytkownika). Jednakże pozwalanie rootowi na logowanie przez SSH nie jest zbyt wielkim zagrożeniem, oczywiście pod warunkiem, że używasz silnego hasła lub wyłączysz potwierdzenie hasła. Jeśli chcesz zabronić potwierdzenie hasła roota, możesz użyć wpisu: PermitRootLogin without-password . Odrzucisz w ten sposób wszystkie podejścia do potwierdzenia hasła na koncie roota, co jest o wiele bezpieczniejsze niż pozwalanie na potwierdzenie hasła. Pamietaj, że możesz też pozwolić na wejście na konto roota jedynie poprzez autoryzację klucza, ograniczonego opcją komendy (patrz konfiguracja klienta SSH). (...)

Słowo kluczowe VerifyReverseMapping jest dobre dla paranoików. Narzuca ono sshd, aby sprawdzało zgodność nazwy odległego klienta (pełnej domeny) z IP. Domyślnie jest to niedostępne.

Słowo kluczowe UsePrivilegeSeparation jest ważną opcją. W wiele kodów w OpenSSH które działały wyłącznie pod rootem, obecnie funkcjonują pod nieuprzywilejowanym użytkownikiem. Ponieważ znacząco podnosi to bezpieczeństwo OpenSSH, powinno się udostępnić cechę UsePrivilegeSeparation . Niestety, opcja ta nie działa zbyt dobrze (w wersji OpenSSH 3.4p1) z innymi systemami unixowymi, można jednak się spodziewać, że następna wersja OpenSSH będzie pozbawiona błędów.

Jest także klika innych opcji wartych wspomnienia, których nie ma w domyślnej konfiguracji Linuksa Mandrake. Pierwszym z nich jest słowo kluczowe AllowUsers. Określa ono, co użytkownicy lub użytkownicy pasujący do określonych wzorów, mogą zmieniać i zapisywać w systemie. Może być to pojedyncza nazwa lub lista rozdzielona spacjami. Możesz także użyć do określenia "calling domains" (czyli wywołania domen) wpisując uzytkownik@host zamiast samego użytkownika. Na przykład:

AllowUsers jasiu

AllowUsers stasiu@remotehost.com

Pozwoli to lokalnym użytkownikom Jasiowi i Stasiowi zalogować się, ale dostęp do Stasia jest jedynie udzielany tym łączącym się z hosta "remotehost.com". Innymi słowy, jeśli użytkownik próbuje zalogować się jako Stasiu, ale łączy się z hosta otherdomain.com, nie dostanie pozwolenia na logowanie. Możesz tu użyć także domenową dzika kartę (wildcards), by określić domenę, jak np. "stasiu@*.remotehost.com". W wildcards mogą być używane znaki "?" (który pasuje do każdego pojedynczego znaku oprócz "@") oraz "*" (który pasuje do każdego ciągu znaków, także prócz "@").

Podobnie możesz użyć słowa kluczowego DenyUsers. Odmówisz w ten sposób wszystkim określonym użytkownikom lub tym pasującym do wzoru. Można użyć domenowych dzikich kart (wildcards) jak w AllowUsers. Uważaj, gdy będziesz używał DenyUsers i AllowUsers jednocześnie, to DenyUsers zawsze będzie miało pierwszeństwo. Na przykład, jeśli odmówiłeś użytkownikom dla wszystkich kont zaczynających się na literę "s" (np. wzór "s*"), a miałeś już wyrażenie AllowUsers dla użytkownika "stasiu", możesz błędnie uważać, że stasiu jest dostępny. Niestety, logowania są dozwolone tylko, gdy nie ma ograniczeń dotyczących nazwy użytkownika. W tym wypadku jest ograniczenie dotyczące "s*" i dlatego stasiu nie zostanie wpuszczony.

Możesz także pozwolić na dostęp bazowany na grupach słów kluczowych z AllowGroups i DenyGroups (jest używana do określania dostępu bazowanego na grupie unix'owej na serwerze). Będzie to sprawdzane w stosunku do podstawowych i dodatkowych grup użytkownika. Działa tylko na nazwy użytkownika, nie ilość. Przykład:

AllowGroups sshusers

DenyGroups users

W tym przykładzie użytkownicy należący do grupy "sshusers" mogą zalogować się w systemie, ale użytkownicy należący do grupy "users" nie mogą. Na Linuksie Mandrake standardem dla każdego użytkownika jest należenie do własnej grupy jako podstawowej (np. użytkownik jasiu będzie najprawdopodobniej należeć do grupy jasiu). Możesz dodawać użytkowników do dodatkowych grup, takich jak "users" lub np. "sshusers". Pamiętaj o ograniczeniach; są one tu takie same jak w bazowanych na użytkowniku słowach kluczowych. Tu, jeśli użytkownik należy do obu grup: users i sshusers, nie dostanie dostępu do logowania.

Wreszcie, jeśli chcesz używać kontroli dostępu opartej na hoście, możesz to zrobić wykonując komendy AllowUsers i DenyUsers, ale bez określania nazwy użytkownika. Na przykład wzór "*@somesite.com" będzie pasował do domeny somesite.com i dotyczy każdego konta na które mogą oni chcieć dostępu.

Pamiętaj, by po każdej zmianie konfiguracji restartować sshd!

ZAKOŃCZENIE

Powinno być jasno stwierdzone, że OpenSSH to duży, elastyczny i z całą pewnością niezbyt łatwy program. By wydobyć możliwie wiele z OpenSSH trzeba przekopać się przez sterty stron i plików konfiguracyjnych. Mam nadzieję, że niniejszy artykuł zilustrował kilka z istotnych opcji, które być może nie były przez Ciebie wcześniej znane.

Jedna końcowa notka: za każdym razem gdy wprowadzasz zmiany w swoim pliku sshd_config, upewnij się że zrestartowałeś sshd za pomocą "service sshd restart" jako root. Zmiany w plikach konfiguracyjnych użytkownika, takich jak ~/.ssh/authorized_keys i ~/.ssh/config nie wymagają restartu demona sshd.

Historia znaleziona na www.mandrakesecure.net/en/docs/openssh.php
This story found at www.mandrakesecure.net/en/docs/openssh.php

Ostatnia modyfikacja: Piątek, 20 września 2002 r.
Last modified: Fri Sep 20 13:03:22 2002

Linux jest zarejestrowanym znakiem towarowym Linus Torvalds. Składniki z tych stron i wszystkie obrazki są zastrzeżone przez właścicieli. Wszystkie składniki tej strony - teksty i loga - są zastrzeżone przez MandrakeSoft SA 2001-2002.
Linux is a registered trademark of Linus Torvalds. The contents of these pages and all images are copyright by their respective owners. All the contents of the pages - texts and logos - are copyrighted by MandrakeSoft SA 2001-2002.

*

Autor niniejszej strony www nie ponosi ŻADNEJ odpowiedzialności za przetłumaczony tekst. Zrobił to WYŁĄCZNIE na swój prywatny użytek i w dobrej wierze udostępnił wyniki pracy.

Strona domowa opracowania i tłumaczeń:
http://gorzow-wlkp.pl

W razie pytań i uwag proszę pisać na adres:
twarogal@poczta.wp.pl

Tłumaczyli: Gosia i Mirek Twarogal

22.03.2003