Protokół SSH jest podstawowym sposobem do zdalnego logowania do serwerów linux oraz przesyłania plików. W tym wpisie omówimy jak wzmocnić domyślną konfigurację, skonfigurować uwierzytelnianie bez hasła oraz wdrożyć jail dla użytkowników Secure File Transfer Protocol (SFTP).

Głównym plikiem konfiguracyjnym ssh jest plik /etc/ssh/sshd_config. W dalszej części wpisu przyjmijmy że pisząc “w konfiguracji” lub “w pliku konfiguracyjnym” mam na myśli właśnie ten plik.

Dodatkowo po wykonaniu każdej zmiany należy zrestartować usługę ssh poleceniem:

Aby bezpłatnie odblokować dalszą treść kliknij "Zapisz się" - dostaniesz nielimitowany dostęp do wszystkich treści i wyślę Ci na maila kilka wyjątkowych bonusów !!
Jeśli jesteś już zapisany - Kliknij "Zaloguj się" i podaj swojego maila - treść zostanie odblokowana:
Zaloguj się lub Zapisz się
Sprawdź Przejdź do zapisu
Anuluj
Dalsza część artykułu jest dostępna tylko dla zapisanych do newslettera. Aby zapisać się do newslettera Kliknij tutaj , lub wypełnij pola w bocznym panelu.
Jeśli jesteś już zapisany - podaj poniżej swój adres e-mail: Odblokuj
adotpay
Anuluj
Zalecam także wykonywać tylko jedną zmianę naraz, i po jej wykonaniu i zrestartowaniu ssh sprawdzić w drugim oknie konsoli czy całość działa poprawnie.

 

1) Wyłączenie protokołu 1 w SSH

Protokół SSH w wersji 1 jest starym i mocno dziurawym protokołem – już dawno temu miał wiele luk (np. CVE-2001-1473) przez co nie jest zalecane jego używanie.

Jeżeli w konfiguracji masz:

lub

to należy to zmienić na:

 

2) Włączenie logowania za pomocą klucza

Parę klucz prywatny i publiczny możemy generować zarówno na systemie windows ( programem puttygen) jak i linux.

Aby wygenerować klucz rsa o długości 4096 bitów ( minimalne zalecenie to 3072 bity) w systemie linux wpisujemy:

Następnie zostajemy poproszeni o podanie hasła, i klucze zostają wygenerowane.

Klucz publiczny domyślnie jest zapisany w pliku /home/uzytkownik/.ssh/id_rsa.pub  , a klucz prywatny /home/uzytkownik/.ssh/id_rsa

Klucz prywatny chronimy tak samo jak i hasła – nikomu go nie podajemy.

Klucz publiczny natomiast wgrywamy na serwer – możemy to zrobić ręcznie kopiując zawartość /home/uzytkownik/.ssh/id_rsa.pub na serwer do pliku /home/uzytkownik/.ssh/authorized_keys ( lub /root/.ssh/authorized_keys jeśli logujemy sie na root-a), lub skopiować go za pomocą polecenia:

 

3) Wyłączenie konta root-a

Jeżeli logujemy się do serwera na konto root-a to w celu bezpieczeństwa powinniśmy dodać nowego użytkownika ( useradd), nadać mu uprawnienia do sudo i następnie wyłączyć konto root-a.

Aby wyłączyć konto root zmieniamy:

na

na systemach Ubuntu ustawienie to ma formę:

co oznacza, że możemy się zalogować na konto roota, ale tylko za pomocą klucza.

 

4) Wyłączenie logowania za pomocą hasła

Jeżeli mamy już wgrane klucze na konto użytkownika, to kolejnym etapem jest wyłączenie logowania za pomocą hasła – odpowiada za to ustawienie “PasswordAuthentication​”. Ustawiamy ją na:

 

5) Zmiana poziomu logowania

Poziomy logowania w ssh to:

  • QUIET
  • FATAL
  • ERROR
  • INFO
  • VERBOSE
  • DEBUG lub DEBUG1
  • DEBUG2
  • DEBUG3

Domyślny poziom logowania to:

W większości zastosowań jest on w pełni wystarczający. Jeżeli natomiast potrzebujemy bardziej szczegółowych informacji o logowaniu, to możemy zmienić poziom na DEBUG1 , 2 lub 3.

Należy przy tym pamiętać, że te poziomy nie są zalecane w działaniu produkcyjnym, gdyż ze względu na poziom szczegółowości naruszają prywatność.

 

6) Białe i czarne listy

W konfiguracji istnieją białe i czarne listy, na podstawie których możemy zezwolić na dostęp do SSH dla danego użytkownika, lub dla danej grupy użytkowników.

Te dyrektywy to:

  • DenyUsers
  • AllowUsers
  • DenyGroups
  • AllowGroups

Dl każdego ustawienia można podać więcej niż jednego użytkownika/grupę – oddzielamy ich spacją.  Trzeba jednak pamiętać iż ustawienia są czytane od góry do dołu według powyższej listy – jeśli dodamy użytkownika jako “DenyUsers”, i “AllowUsers” to użytkownik ni będzie miał dostępu. Anlogicznie – jeśli będzie jako “AllowUsers” ale jego grupa będzie jako “DenyGroups” o dany użytkownik również będzie miał dostęp.

 

7) Białe i czarne listy IP

Poza tworzeniem białych i czarnych list w konfiguracji możemy też skonfigurować takie same listy dla adresów/podsieci ip.  Jeżeli korzystasz z własnego VPN-a ze stałym adresem ip warto dodać tą dodatkową warstwę bezpieczeństwa.

Listy tworzysz w dwóch plikach:

  • /etc/hosts.allow
  • /etc/hosts.deny

Format dodawania wpisu to:

Tak samo jak w przypadku list zawartych w konfiguracji – najpierw jest czytany plik hosts.allow , a dopiero hosts.deny. Jeżeli w pliku hosts.allow będzie dozwolony dostęp do danego ip to automatycznie plik hosts.deny nie będzie weryfikowany.

Przypominam ponownie, iż zawsze po dokonaniu zmian i restarcie należy sprawdzić połączenie do serwera – jeżeli za dużo zablokujemy w hosts.deny i stracimy dostęp poprzez ssh to jedyną opcją naprawy jest wizyta w serwerowni lub awaryjne  podłączenie się do serwera ( kvm,ipmi).

Z własnego oświadczenia – jeśli masz kilka zaufanych ip łączących się do serwera, dodaj je do pliku /etc/hosts.allow według powyższego wzoru,  a w pliku hosts.deny dodaj:

 

8) Automatyczne wylogowanie po x sekundach bezczynności

Dobrą praktyką jest blokowanie ekranu komputera gdy musimy gdzieś na chwilę wyjść. W większości urządzeń można ustawić automatyczne blokowanie i wygaszanie ekranu – warto to samo zrobić z naszymi połączeniami do ssh.

Są dwie metody blokady – jedna d wylogowania użytkowników zalogowanych zarówno lokalnie jak i zdalnie, druga dla tych zalogowanych zdalnie.

Metoda pierwsza – użytkownicy zalogowani lokalnie i zdalnie:

W katalogu /etc/profile.d/ tworzymy plik wyloguj.sh o treści:

nadajemy mu uprawnienia:

Po wylogowaniu i ponownym zalogowaniu po 60 sekundach zostaniemy wylogowani:

 

Metoda druga- użytkownicy zalogowani zdalnie

Aby włączyć automatyczne wylogowywanie w pliku konfiguracyjnym znajdź ( lub dodaj jeśli ich nie ma):

Następnie zrestartuj usługę ssh. Po wylogowaniu i ponownym zalogowaniu do ssh jeśli przez 60 sekund nie wykonasz żadnej akcji sesja zostanie zerwana.

 

9) Komunikat po nawiązaniu połączenia

Nie należy go traktować jako zabezpieczenia, a raczej analogicznie do okienek o rodo/ciasteczkach przy pierwszym odwiedzeniu strony.

Jeżeli chcemy poinformować użytkowników o tym gdzie sie logują i jakie mogą być tego konsekwencje, możemy to zrobić za pomocą bannera.

Tworzymy plik /etc/ssh/sshd-banner i umieszczamy w nim dowolny tekst – np “Logujesz się do serwera xxx – twój adres ip oraz wszystkie wykonywane polecenia będą logowane.”

Następnie w pliku konfiguracyjnym zmieniamy:

na

i tradycyjnie restartujemy ssh i logujemy się ponownie.

Teraz po podaniu ip otrzymamy informację z pliku:

 

10)Przekierowanie X11

Domyślnie łączymy się do ssh w trybie tekstowym, natomiast jest jeszcze opcja, by przy użyciu odpowiedniego przełącznika (“-Y” lub “-X”) uruchomić programy oparte o GUI. Sam protokół X11 nie jest jednak zbyt bezpieczny i jeśli nie potrzebujemy trybu graficznego zalecane jest jego wyłączenie.

Aby to zrobić odnajdujemy w konfiguracji:

i zmieniamy na

 

11) Wyłączenie tunelowania SSH

Tunelowanie, czy przekierowanie portów SSH jest używane m.in. gdy chcemy cały ruch z naszego komputera przekierować przez serwer. Jest to szybki i wygodny sposób, jednak też bardzo niebezpieczny, dlatego zaleca się wyłączenie możliwości tunelowania, szczególnie w środowisku produkcyjnym.

Aby wyłączyć możliwość tworzenia tuneli SSH ustawiamy:

 

12) Zmiana portu SSH

Standardowy port ssh nie jest bezpiecznym rozwiązaniem – nawet jeśli wdrożymy wszystkie powyższe punkty to warto zmienić go chociażby po to, by roboty automatycznie skanujące adresacje nie wykonywały prób połączeń i tym samym nie generowały zbędnego ruchu.

Za numer portu odpowiada zmienna o tej samej nazwie – “Port”. Wystarczy więc zmienić numer portu i zrestartować serwer ssh.
Jeżeli korzystamy z firewalla należy też otworzyć nowy port ssh i zezwolić na połączenie do niego.

 

13) Pozostałe ustawienia konfiguracyjne

Jeżeli dotarłeś do tego miejsca i wdrożyłeś wszystkie powyższe podpunkty – gratuluję, połączenie do ssh do twojego serwera jest już o wiele bezpieczniejsze.

Konfiguracja ssh ma jeszcze sporo innych ustawień, o których nie wspominałem w tym wpisie. Polecam poczytać o nich i dokonać dodatkowych zmian według własnego uznania – szczególnie interesująca może być kwestia zasad kryptograficznych.