Autorem artykułu jest Kamil Michalak
Niekiedy przychodzi taki czas, że musimy dostać się do naszego komputera domowego, czy serwera z jakiegoś odległego miejsca. Co wtedy robić? Najlepiej skorzystać z SSH.
Wiele osób pisząc na temat SSH, czyli Secure Shell zaczyna od jego historii. Ja jednak pominę ten krok przechodząc do konkretów. Mówiąc SSH mamy na myśli określony standard protokołów komunikacyjnych wykorzystywanych w sieciach TCP/IP. Niestety przez wielu jest kojarzony głównie jako następnik telnetu. Jak się jednak okazuje SSH można wykorzystać nie tylko jako bezpieczną powłokę dla zdalnego logowania się na odległym hoście, lecz również do tunelowania, zdalnej administracji, przesyłania plików czy forwardowania.
Konfigurację protokołu SSH, jego działanie i zastosowanie postaram się przybliżyć na przykładzie systemu GNU/Linux a dokładniej Debiana 5.0 Sid.
Powszechnie wiadomo, że Debian posiada największy zbiór prekompilowanych pakietów, które tylko czekają na to, aby zainstalować je na dysku twardym komputera. Z tego też powodu nie musimy podejmować prób instalacji SSH ze źródeł. Nam wystarczy gotowy pakiet dostępny w repozytorium. Instalujemy go poleceniem
# apt-get update && apt-get install ssh
Należy przy tym pamiętać, że do instalacji paczek konieczne są uprawnienia użytkownika root. Czekamy cierpliwie na pobranie naszej paczuszki i wkomponowanie jej w nasz system.
W katalogu /etc powinien pojawić się nowy folder o nazwie ssh. W jego wnętrzu znajduje się podzielona na kilka plików konfiguracja.
Najważniejszymi z nich są sshd_config (konfiguracja serwera SSH) oraz ssh_config (ustawienia klienta) i głównie na nich należy się skupić. Budowy i znaczenia poszczególnych opcji zawartych w tym pliku nie będę raczej objaśniał, gdyż mogłoby stać się to tematem odrębnego artykułu.
Skoro nasza maszyna ma już zainstalowane odpowiednie pakiety zajmijmy się ich konfiguracją. Korzystając z uprawnień roota edytujemy plik /etc/ssh/sshd_config.
# vim /etc/ssh/sshd_config
Standardowo naszym oczom powinien ukazać się plik zawierający około 80 linii.
Na domyślnych ustawieniach serwer SSH nasłuchuje na porcie 22. Z doświadczenia jednak wiem, że jeżeli ktoś ma ochotę włamać się na serwer to sprawdza właśnie ten port. A nuż administrator nie miał weny przy wymyślaniu skomplikowanego hasła i użył swojego loginu, lub kombinacji jego liter. Stąd też dobrą praktyką jest zmiana portu. Aby to zrobić wyszukujemy linijki Port 22 i zmieniamy wartość liczbową na inną nam odpowiadającą, np. 1810.
Zmieniamy również Protocol 2 , 1 na Protocol 2 i zaraz potem przeskakujemy do wiersza PermitRootLogin podmieniając jego wartość z yes na no. Teraz małe wyjaśnienie co do dwóch kolejnych modyfikacji. Pierwsza wymusza użycie wyłącznie drugiej wersji protokołu SSH, zamiast zezwalać na korzystanie z pierwszej i drugiej wersji. Jaki w tym cel? Po pierwsze, SSH1 jest dość mocno podatne na ataki kryptoanalityczne. Wada ta została ograniczona w następnej wersji. Drugim powodem dla użycia SSH 2 jest dużo większa liczba możliwych metod szyfrowania, oraz obecność 4 sposobów uwierzytelniania. Drugi zabieg konfiguracyjny polega na uniemożliwieniu logowania się z wykorzystaniem SSH bezpośrednio na konto roota. Dzięki temu ograniczymy możliwość przechwycenia hasła administratora i zmniejszymy ryzyko utraty kontroli nad systemem. Skoro już zmieniliśmy typ protokołu, czas na następny krok – włączmy uwierzytelnianie przy pomocy klucza publicznego. Robimy to wstawiając w pliku dwie linijki (jeżeli ich nie ma, jeżeli są, to tylko modyfikujemy) PubkeyAuthentication yes i AuthorizedKeysFile .ssh/authorized_keys. Zadanie pierwszego wiersza jest raczej oczywiste, decyduje on o korzystaniu z uwierzytelniania wybraną przed chwilą metodą. Druga linia opisuje natomiast położenie naszych kluczy.
Osoby niecierpliwe już teraz mogą uruchomić drugi emulator terminala i wygenerować klucze poleceniem
$ ssh-keygen -t dsa
Po wydaniu tego polecenia powinniśmy zostać poproszeni o hasło, po czym zostaniemy obrzuceni kilkoma komunikatami, a na końcu w katalogu ~/.ssh/ zostaną utworzone pliki id_dsa i id_dsa.pub. Zasada ich działania jest prosta. Pierwszy klucz jest naszym prywatnym kluczem, którego powinniśmy strzec jak oka w głowie. Drugi zaś kopiujemy do katalogu ~/.ssh/authorized_keys (tak, zgadza się, tutaj nie ma ukośnika na końcu, ponieważ jest to plik, a nie folder) na naszym zdalnym serwerze, a potem możemy już o nim zapomnieć.
Wróćmy jednak raz jeszcze do pliku konfiguracyjnego (/etc/ssh/sshd_config). Jak pamiętamy wyłączyliśmy możliwość bezpośredniego połączenia się z serwerem przez SSH dla konta roota. Aby dostać uprawnienia super użytkownika należy teraz logując się na zwykłe konto użyć polecenia „su -”. Po wpisaniu hasła możemy zwyczajnie pracować na maszynie jako administrator.
Przejdźmy teraz do pliku /etc/group. Starym, znanym dobrze sposobem dopisujemy w nim wiersz “wheel:x:10:root,kazio,stasio,maniek”, gdzie kazio, stasio i maniek to nazwy użytkowników, którym chcemy przydzielić uprawnienia do korzystania z polecenia su. Po zapisaniu pliku wydajemy polecenia
# chgrp wheel /bin/su
# chmod o-rwx /bin/su
Od tej chwili tylko i wyłącznie root, oraz podani wcześniej użytkownicy mają prawo dostępu do polecenia su.
Sens tej metody jest jasny. Każdy kto zechce skorzystać z konta administratora systemu, będzie musiał najpierw zalogować się na jedno z kont podanych w pliku /etc/group. Czyli tak na prawdę uzyskanie uprawnień roota wymaga podania dwóch haseł, przy czym musimy jeszcze wiedzieć, który z użytkowników ma w ogóle prawo do korzystania z przełączenia użytkownika. Jest to kolejna kłoda rzucona pod nogi potencjalnemu włamywaczowi. Wykończeniem konfiguracji tego konkretnego zabezpieczenia jest dodanie do konfiguracji SSH linii AllowGroups wheel. Określa ona, którzy użytkownicy mają w ogóle prawo do zdalnego logowania z użyciem bezpiecznej powłoki. Jeżeli jednak nie mamy ochoty nadawać uprawnień dla całej grupy, możemy użyć opcji AllowUsers stasio rysio, która nada przywileje tylko wybranym. Analogicznie możemy odciąć dostęp dla danych użytkowników korzystając z parametru DenyUsers.
Artykuł pochodzi z serwisu www.Artelis.pl
Brak komentarzy:
Prześlij komentarz