|
wersja 0.1 |
|
Spis treści |
1. Zaczynamy 2. Wara od serwera! 3. Konfig serwera 4. sFTP 5. Klucz zamiast hasła * klucze * serwer * klient 6. ssh Posłowie |
| 1. Zaczynamy |
Dokument ten należy traktować jako wprowadzenie do SSH. Opisuje on kilka podstawowych, najczęściej stosowanych funkcji. Jeśli zajdzie potrzeba zostanie on rozbudowany (proszę o mejle: co rozbudować / co dopisać). Na temat SSH napisano już wiele. W tym dokumencie mam zamiar "na szybkiego" opisać kilka funkcji oraz rozwiązań mogących zaistnieć na Twoim serwerze. Wszystko, co znajduje się niżej testowałem między Slackiem 8.0 (serwer) a Slackiem 9.0/Windą 98. Wykorzystałem wersję 3.6.1 (paczlewel 2) OpenSSH pobranym ze strony www.openssh.org. Jeszcze jedna ważna uwaga (podziękowania dla SirRomana): w Twoim systemie powinien istnieć użytkownik sshd, więc jeśli go nie ma: useradd -s /bin/false -d /dev/null sshd Aby zainstalować to całe tałatajstwo, po rozpakowaniu wydałem następujące polecenia: ./configure --sysconfdir=/etc/ssh --with-tcp-wrappers --with-md5-passwords make make install Pod innymi systemami (np. RedHat czy Mandrake) zamiast --with-md5... należy wywołać --with-pam (przynajmniej tak mi się wydaje). Jeśli dostaniesz błąd na temat wrappersów będziesz musiał albo je pominąć albo zainstalować odpowiednie biblioteki. No i wygląda na to, że będziesz musiał utworzyć użytkownika sshd jeśli takowego nie posiadasz - po nawiązaniu połączenia nasz serwer będzie chodził na jego prawach. Z instalacją powinieneś sobie poradzić, dlatego odpuszczam sobie dokładny opis. Pliki konfiguracyjne znajdują się w katalogu /etc/ssh/, natomiast serwer uruchamiam poleceniem /usr/local/sbin/sshd. Zatrzymuję go poleceniem killall sshd. Działa to wszystko szybko i bez problemu a jeśli ktoś chce się bawić w skrypty - proszę bardzo :) |
| 2. Wara od serwera! |
Po instalacji serwer SSH jest gotowy do działania. Z grubsza. Tak czy siak, można go uruchomić. To co napiszę tutaj, powinno znaleźć się na końcu pracy w części "(ważne) pierdoły" ale jeśli teraz tego nie robię - zapomnę o tym. Logowanie zabronione Wystarczy utworzyć plik /etc/nologin, a tylko root będzie mógł się zalogować na serwer przez SSH (o ile jego konfiguracja na to pozowli). Inni userzy, próbujący się zalogować - nie zostaną wpuszczeni. Ich oczy ujrzą po prostu nic (jeśli /etc/nologin będzie pusty) albo zawartość wspomnianego pliku (np. "Wróć za 30 minut. Cała moc serwera liczy Seti."). W momencie usunięcia /etc/nologin userzy mogą normalnie się logować przez SSH. Kto może a kto nie Jeśli SSH zostało skomipilowane z opcją --with-tcp-wrappers możemy pozwolić (lub nie) na połączenia na podstawie adresu IP klienta. Pewnie i tak wiesz, o co chodzi, dlatego będę się streszczał. Jeśli w pliku /etc/hosts.deny umieścisz wpis: sshd: ALL to zgadnij co ? Taaaak jest, nikt nie będzie mógł się połączyć z naszym serwerem przez SSH. Jeśli zamiast ALL wpiszesz adres(y) IP, wtedy odrzucane będą połączenia (z SSH) z tych adresów. W analogiczny sposób działa plik /etc/hosts.allow, tyle że definiujemy w nich klientów, którzy są dopuszczani do poszczególnych usług. Pliki hosts.allow i hosts.deny stanowią zgrany duet i są dobrym sposobem na szybką zmianę praw dostępu do naszej usługi. Informacje w nich zawarte są sprawdzane przy każdym połączeniu, dlatego też naszego SSH nie musimy przeładowywać, wszystko działa "od razu". Ważna uwaga: najpierw sprawdzany jest plik allow - jeśli klient znajduje się na liście to jest on dopuszczony do usługi i reszta nie jest sprawdzana. Jeśli tam go nie ma, sprawdzany jest deny - jeśli nasz klient znajduje się tutaj - dostęp do naszej usługi jest odmówiony i tyle. Jeśli gościa nie ma ani tu, ani tam - następuje połączenie z usługą - klient jest dopuszczony. Na koniec przypomnę tylko, że klientów możemy definiować: - adresami IP (np. 192.168.1.5), - słowami ALL oraz LOCAL, - nazwami domenowymi (np. serwer1.serwer.pl), - częściowymi adresami IP (np. 192.168. ), - częściowymi nazwami domenowymi (np. .serwer.pl), - składnią sieć/maska (np. 192.168.1.0/255.255.255.0 :), - wykorzystując słowo EXCEPT ("za wyjątkiem"). Dobra, wystarczy. Pobaw się tym trochę - fajna sprawa. Więcej szczegółów znajduje się w man 5 hosts_access. |
| 3. Konfig serwera |
Plik konfiguracyjny naszego serwera SSH znajduje się w katalogu /etc/ssh/ a jego imię to sshd_config. Proponuję umieścić w nim następujące rzeczy na początek: # --------- ogólne # na którym porcie siedzi serwer Port 22 # obsługiwane wersje SSH Protocol 2,1 # nasłuchuje na wszystkich kartach sieciowych # zmiana: wpisz odpowiedni IP ListenAddress 0.0.0.0 # ---------- klucze (standardowo) # RSA dla wersji 1 SSH HostKey /etc/ssh/ssh_host_key # RSA i DSA dla wersji 2 SSH HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # ---------- logi SyslogFacility AUTH LogLevel INFO # ---------- logowanie # czas w sekundach LoginGraceTime 60 # czy bezpośrednio root może się zalogować # nie ma się czego bać, wystarczy dobre hasło PermitRootLogin yes # czy dozwolone "puste" hasła PermitEmptyPasswords no # --------- zalecane # czy sshd działa jako inny user UsePrivilegeSeparation yes # serwer nie ma iksów (okienek) ! X11Forwarding no # środowisko usera z authorized_keys PermitUserEnvironment no # kompresja Compression yes # tego nie ruszamy, są lepsze sposoby ChallengeResponseAuthentication no # jakiś plik dla kluczy userów AuthorizedKeysFile .ssh/authorized_keys # --------- pierdoły # wyświetlony przez podaniem hasła # utwórz sobie jakieś powitanie Banner /etc/ssh/banerek.ssh # "wiadomość dnia" PrintMotd yes # info o ostatnim logowaniu PrintLastLog yes # --------- ważne # wyłączenie głupiego i niebezpiecznego badziewia RhostsRSAAuthentication no HostbasedAuthentication no # W obecnych wersjach openssh RHostsAuthentication # zostal usuniety # RhostsAuthentication no IgnoreRhosts yes # -------------- tutaj będziemy mieszać --------------- # eFTePa na razie nie włączamy #Subsystem sftp /usr/local/libexec/sftp-server # tutaj dochodzimy do sedna sprawy ! PasswordAuthentication no PubkeyAuthentication no Powyższą konfigurację serwera można uznać za bezpieczną - na razie nikt nie może się zalogować... Telnet Jeśli teraz chcemy umożliwić "normalne" logowanie naszym użytkownikom wystarczy zmienić parametr PasswordAuthentication na yes i przeładować sshd. W ten oto sposób otrzymamy bezpieczny odpowiednik telneta. A skoro jesteśmy już przy logowaniu, to poruszę jeszcze ciekawe opcje: DenyUsers heniek czesiek@klient.pl t* - serwer nie wpuści użytkownika czesiek łączącego się z klient.pl, użytkownika heniek oraz każdego in nego, którego login zaczyna się na literę "t". DenyUsers * - serwer nie wpuści żadnego użytkownika :) Podsumowując: jeśli w sshd_config użyta zostaje opcja DenyUsers - wszyscy użytkownicy mogą logować się na serwer za wyjątkiem tych wymienionych. Analogicznie działa AllowUsers :jeśli ta opcja zostaje użyta, logować na serwer mogą się tylko wymienieni użytkownicy - pozostałym dostęp jest odmawiany. Aby jeszcze bardziej zamotać, dodam - istnieją bardzo podobne opcje dla systemowych grup użytkowników: AllowGroups oraz DenyGroups. Można utworzyć w systemie dodatkową grupę użytkowników - takich, którzy mają dostęp do serwera SSH. Jeśli w sshd_config nie zostaje użyta żadna z opcji Allow/Deny - nasz serwer dopuszcza logowanie się wszystkich użytkowników. |
| 4. sFTP |
Na wielu komputerach serwer FTP jest zainstalowany tylko po to, aby jeden lub dwóch użytkowników mogło przerzucać kilka plików (np. kopie zapasowe). Po pierwsze: hasło i dane przerzucane są FTP w postaci jawnej (nie są one szyfrowane). Po drugie: na serwerze udostępniona jest dodatkowa usługa mogąca stanowić lukę w bezpieczeństwie (dziura w kodzie, zła konfiguracja itp.). Tymczasem nasz SSH oferuje swój serwer(ek) FTP - sftp. Nie jest on może zbyt rozbudowany, ale szyfruje wszystko i nie trzeba się martwić o dodatkową usługę (w postaci "normalnego" FTP). Aby włączyć eftepa przez nasze SSH wystarczy umieścić (zmienić wartość) jednego parametru w pliku sshd_config: Subsystem sftp /usr/local/libexec/sftp-server Po przeładowaniu sshd możemy się eftepować. Pytanie - czym ? Klienci sFTP Po instalacji naszego SSH otrzymaliśmy dwa programy potrafiące łączyć się i przesyłać pliki przy pomocy SFTP: są to scp oraz sftp. Zaczniemy od prostszego... 1. scp Polecenie scp jest bardziej podobne do polecenia systemowego cp (kopiuj) niż do ftp. Nie jest to program interaktywny, nie ma w nim takich poleceń jak get, put, hash. Zakładam, że serwer SFTP znajduje się na komputerze serwer.pl. Oto kilka przykładów użycia: scp heniek@serwer.pl:backup.tar.gz . - kopiuje plik backup.tar.gz z katalogu domowego użytkownika heniek na sererze serwer.pl do bieżącego katalogu. scp -r heniek@serwer.pl:public_html . - kopiuje (-r: rekursywnie) katalog public_html z katalogu użytkownika heniek na serwerze serwer.pl do bieżącego katalogu. scp -l 100 -C httpd.conf heniek@serwer.pl:backup/ - kopiuje plik httpd.conf z bieżącego katalogu do podkatalogu backup w katalogu domowym użytkownika heniek na serwer.pl. Dodatkowo "w locie" wykonywana jest kompresja tego pliku (-C) a szybkość jego przerzucania po sieci ograniczona jest (-l) do 100 kilobitów na sekundę. Jak wspomniałem wcześniej, jest to polecenia bardzo podobne do kopiowania. Jedna z różnic polega na tym, że w wyżej wymienionych przykładach należy podać hasło użytkownika heniek na serwer.pl. scp wyświetla także bardzo ładny pasek postępu w trybie tekstowym :) 2. sftp Jak już pewnie się domyślasz, polecenie sftp jest odpowiednikiem polecenia ftp. Jest to program interaktywny, pracujący także w trybie teksowym. Są w nim dostępne takie polecenia jak mkdir, get, put, chmod itp. Dodam jeszcze, że sFTP obsługiwane jest tylko przez drugą wersję SSH. Oto kilka przykładów użycia narzędzia: sftp -C heniek@serwer.pl - połączenie się przez sFTP z serwerem serwer.pl jako użytkownik heniek. Kompresja "w locie" jest włączona (-C). Po podaniu hasła pracujemy jak ze zwykłym poleceniem ftp. sftp -C heniek@serwer.pl:/etc/hosts hosts.bak - pobranie z serwer.pl jako użytkownik heniek pliku /etc/hosts i zapisanie go w bieżącym katalogu pod nazwą hosts.bak. Ten przykład pokazuje, że sftp może pobierać pliki w podobny sposób do scp. Klienci sFTP dla Windows Teraz parę słów o oprogramowaniu klienckim dla najlepszych istniejących systemów operacyjnych. W ogóle powinniśmy być wszyscy wdzięczni Billowi G. :). Dobra: istnieje oprogramowanie klienckie dla Windows. Pobrać je można ze strony domowej programu PuTTY. Programy te nazywają się: pscp oraz psftp. Tak prawdę mówiąc, proponuję pobrać plik putty.....installer.exe - znajduje się w nim wiele programików, które może wykorzystać WinShit do bezpiecznego łączenia się z naszym serwerem. Wyżej wymienione polecenia działają w trybie tekstowym (o nie!) a ich składnia jest bardzo podobna do tych Juniksowych. Ale porządny Windziarz to taki, który z trybem tekstowym nie ma nic wspólnego. Dlatego też powstała "nakładka" na wyżej wymienione programy - umożliwia ona pracę trybie graficznym. Omawiany program nazywa się WinSCP i pobrać go można (podobnie jak PuTTy - za friko) stąd. |
| 5. Klucz zamiast hasła |
To będzie ciekawy punkt. Jak wiadomo, szyfrujące algorytmy asymetryczne charakteryzują się parą kluczy pasujących tylko do siebie. Jedną z ich cech jest fakt, że "poznanie", udostępnienie jednego z tych kluczy i tak nie zdradza drugiego z nich (zgadywanie "siłowe" jest praktycznie niemożliwe). Zostało to wykorzystane w SSH - istnieje możliwość logowania się do zdalnego systemu nie za pomocą hasła a właśnie klucza. Sprawa wygląda tak: jeden z kluczy (publiczny) zostaje umieszczony na zdalnym serwerze. Drugi z nich, klucz prywatny, trzymany jest w postaci zaszyfrowanej na dysku, komputerze klienckim. Jeśli chcemy się zalogować, wpisujemy hasło aby odszyfrować nasz klucz prywatny a SSH dokonuje reszty - sprawdzone zostaje czy klucze pasują do siebie i jeśli tak jest - logujemy się bez wpisywania hasła systemowego do docelowego komputera. Jaką przewagę ma logowanie się za pomocą klucza nad zwykłym logowaniem do systemu ? Ano taką, że potencjalny intruz, chcący dostać się do shella na naszym serwerku musi zdobyć i nasz klucz prywatny i nasze hasło do klucza. Znajomość samego hasła do klucza (np. przez podpatrzenie) nic mu nie da bez klucza. Podobnie w przypadku zdobycia klucza (przez podpierdolenie - np. dyskietki) - bez hasła nie ruszy. Dodatkową zaletą naszej pary kluczy jest fakt, że za ich pomocą możemy dostać się do kilku naszych serwerów przy pomocy jednego tylko hasła (do klucza). Jeśli hasło jest wystarczająco dobre - jest pięknie :) No i może jeszcze jedna zaleta takiego roz wiązania - odpada możliwość dostania się do systemu przez "zgadnięcie" hasła systemowego - jeśli SSH umożliwia tylko logowanie się przy pomocy kluczy, nie jest możliwe zgadywanie haseł. No, chyba jesteś już przekonany. * klucze Nadszedł już czas, aby wygenerować sobie potrzebne klucze. Poniższe polecenie wykonujemy na komputerze z którego będziemy się łączyć. Okej, stwórzmy sobie parę kluczy RSA: ssh-keygen -t rsa Powstanie w ten sposób para kluczy RSA dla drugiej wersji SSH. Jest to typ najczęściej zalecany. Inne możliwości to -t dsa -wynikiem będzie para DSA dla SSH2 lub (używać w ostateczności) -t rsa1 -para kluczy RSA dla SSH1. Po wygenerowaniu kluczy musimy wpisać hasło zabezpieczające nasz klucz prywatny. W wyniku powyższej operacji powstają nam w katalogu domowym, w (ukrytym) podkatalogu .ssh/ pliki id_rsa (prywatny, chroniony hasłem oraz odpowiednimi prawami dostępu) a także id_rsa.pub (klucz publiczny, który za chwilę "wyślemy w świat"). Jeśli któregoś pięknego dnia stwierdzisz, że hasło chroniące Twój klucz prywatny należy zmienić, wystarczy że wydasz polecenie: ssh-keygen -p -f .ssh/id_rsa Może jeszcze wspomnę, że stosowane tu nazwy plików z kluczami są nazwami domyślnymi - oczywiście można je zapisać bardziej "z sensem" np. serwer_pl.rsa itp. ale to jest zabawa dla koneserów :) * serwer Konfiguracja serwera, aby umożliwił on logowanie się za pomocą kluczy ogranicza się do ustawienia jednej opcji w pliku sshd_config: PubkeyAuthentication yes Należy tutaj poruszyć jeszcze dwie istotne w tym miejscu opcje: PasswordAuthentication no AuthorizedKeysFile .ssh/authorized_keys Pierwsza z nich (już nam znana) wyłącza "zwykłe" logowanie się. Na razie zostaw tą wartość ustawioną na yes. Druga z nich definiuje plik (w naszym przykładzie wartość domyślna) w którym trzymane będą klucze publiczne użytkowników chcących zalogować się na nasz serwer. Do tej drugiej opcji zaraz wrócimy. Po przeładowaniu demona sshd nasz serwer powinien zacząć przyjmować klucze. I jeszcze jedna rzecz: jeśli umożliwimy logowanie się przez SSH i za pomocą kluczy i za pomocą "zwykłego" hasła - jak zachowa się serwer w momencie przyjścia połączenia ? W skrócie: najpierw sprawdzi on po stronie klienta czy istnieje odpowiedni klucz - jeśli tak - logowanie odbędzie się za pomocą kluczy (bardziej bezpieczny sposób). Jeśli nie znajdzie odpowiedniego klucza - rozpocznie się zwykłe, normalne logowanie. Dobra, konfigurację serwera mamy z głowy - reszta w rękach userów. Powinni oni na serwerze, komputerze docelowym umieścić kopię swojego klucza publicznego... * klient Załóżmy, że komputer z którego łączy się Heniek nazywa się klient.pl. Kompem docelowym jest... serwer.pl. Załóżmy także, że Heniek wygenerował już sobie parę kluczy RSA. Co jeszcze powinien zrobić Heniek ? Wystarczy tylko, że swój klucz publiczny (tutaj: id_rsa.pub) umieści na komputerze z którym będzie się łączył (tutaj: serwer.pl). Jeśli przypomnimy sobie teraz plik sshd_config na komputerze docelowym natrafimy na zmienną: AuthorizedKeysFile .ssh/authorized_keys To ona właśnie definiuje w którym pliku użytkownika powinny znajdować się klucze publiczne. Podsumowując: Heniek przerzuca na serwer.pl swój klucz publiczny id_rsa.pub i dopisuje go do pliku authorized_keys w podkatalogu (ukrytym) .ssh swojego katalogu domowego. Jeśli plik ten nie istnieje, Heniek musi go utworzyć i dopisać do niego zawartość klucza publicznego: cd .ssh/ touch authorized_keys cat id_rsa.pub >> authorized_keys chmod 600 authorized_keys rm id_rsa.pub Każdy kolejny klucz publiczny Heniek dopisuje do authorized_keys ograniczając się do polecenia np. cat id_dsa.pub >> authorized_keys Dobrze jest na koniec usunąć ten pierwszy. Jeszcze raz przypomnę, że opisane przed chwilą polecenia wykonuje się na serwerze, komputerze docelowym. I to już wszystko - powinno działać. O ile nie zrobiłeś literówki i przeładowałeś sshd. Hasło które musisz podać przy logowaniu się na serwer jest hasłem chroniącym Twój klucz prywatny (tutaj: id_rsa). |
| 6. ssh |
Hmmm... nie będzie niespodzianką dla Ciebie jeśli napiszę, że do łączenia się ze zdalnymi serwerami przez SSH i pracy na nich wykorzystuje się program ssh. Nie ma tutaj o czym pisać, więc przykładzik: Niech użytkownik Heniek ma konto henryk na serwerze serwer.pl. ssh -l henryk serwer.pl ssh henryk@serwer.pl Powyższe polecenia oznaczają dokładnie to samo: logowanie się jako henryk na zdalny komputer serwer.pl Jeśli na komputerze Heńka znajduje się klucz prywatny pasujący do jego klucza publicznego (umieszczonego na serwer.pl) Heniek zostanie poproszony o wpisanie hasła do klucza. W przeciwnym wypadku dojdzie do zwykłego logowania się na serwerze przy pomocy hasła systemowego. Z ciekawszych opcji programu należy wymienić: -C :zostaje włączona kompresja -2 :łączy się jedynie przy pomocy wersji drugiej SSH -i klucz_prywatny :wykorzystuje klucz prywatny zapisany w podanym pliku I stosowny przykładzik: ssh -C -i serwer_pl.key henryk@serwer.pl Jeszcze ciekawostka: można ułatwić sobie życie wykorzystując plik .ssh/config. Jeśli nie istnieje, należy go utworzyć. Jeśli weźmiemy pod uwagę ostatnie polecenie, możemy dojść do wniosku że naszego Heńka zaczną boleć palce. Oto jak może ułatwić on sobie życie - wystarczy że na komputerze z którego się łączy Heniek umieści w pliku config on coś takiego: Host serwerek HostName serwer.pl User henryk Compression yes IdentityFile serwer_pl.key Wówczas po wydaniu prostego polecenia: ssh serwerek zostanie on połączony jak w ostatnim przykładzie (i może przestaną go boleć palce). Klient ssh dla Windows Użytkownicy Windows nie mają co narzekać. Rewelacyjnym klientem ssh dla ich "systemu operacyjnego" jest PuTTY. Pobrać go można ze wspomnianej wcześniej strony. Jeszcze raz proponuję ściągnąć cały zestaw programików putty...installer.exe. Znajduje się tam także programik PuTTYgen służący generowaniu kluczy, ich eksportem oraz importem. Sam PuTTY umożliwia łączenie się za pomocą kluczy i posiada duże możliwości konfiguracyjne. Jest programem intuicyjnym - wystarczy tylko trochę poklikać :) Podsumowując: użytkownicy Łindołsów posiadają dobre, w pełni funkcjonalne i darmowe narzędzia do łączenia się z wykorzystaniem SSH na różne sposoby. Także wspomniany wcześniej programik WinSCP posiada możliwość logowania się na serwerze z wykorzystaniem klucza wygenerowanego wcześniej przez PuTTYgen. Dobra, chyba wystarczy tego jak na "wprowadzenie"... |
| Posłowie |
Jest to pierwsza wersja tego dokumentu i zawiera pewnie jakieś błędy/niedoróbki/potknięcia itp. Będę bardzo wdzięczny za wszelkie uwagi, komentarze, poprawki, wyrazy wdzięczności. Z góry przepraszam za powyższe i mam nadzieję, że będziecie mnie informować w których miejscach coś nie gra. Jako (częściowe) wytłumaczenie przedstawiam fakt, że większość tej pracy powstawała w późnych godzinach nocnych. Ostatnia wersja tego dokumentu znajduje się pod niżej wymienionym adresem. Kontakt ze mną: linio@terramail.pl Wesprzyj finansowo autora - kliknij tutaj |
|
=============================== Henryk Liniowski, Poznań 2003 http://linio.terramail.pl =============================== |