Jak bezpiecznie skonfigurować SSH na serwerze VPS

Dlaczego SSH jest pierwszym elementem do zabezpieczenia

SSH służy do zarządzania serwerem, co czyni go głównym celem każdego ataku. W momencie, gdy VPS uzyskuje dostęp do sieci, skanery zaczynają próbować odgadnąć nazwy użytkowników i hasła na porcie 22. Można zaobserwować to zjawisko w logach w ciągu kilku minut. Zabezpieczenie SSH polega na wyeliminowaniu elementów, które można odgadnąć: należy całkowicie wyłączyć logowanie hasłem, wyłączyć logowanie dla konta root i zezwolić wyłącznie na dostęp przy użyciu kluczy kryptograficznych. Po wykonaniu tych kroków ciągłe próby odgadnięcia hasła stają się nieskuteczne, ponieważ nie istnieje hasło, które można złamać.

Poniższe kroki zakładają, że SSH jest już skonfigurowane i działa. Jeśli logowanie jest możliwe, można przystąpić do zabezpieczania. Należy wykonywać kroki w podanej kolejności i nie zamykać bieżącej sesji, dopóki nowa nie zostanie poprawnie zweryfikowana. Pozwala to uniknąć utraty dostępu do serwera w przypadku błędu.

Krok 1: Upewnij się, że uwierzytelnianie kluczem działa poprawnie

Uwierzytelnianie kluczem zastępuje hasło parą kluczy: kluczem prywatnym, który pozostaje na komputerze, oraz kluczem publicznym umieszczonym na serwerze. Serwer weryfikuje posiadanie klucza prywatnego bez konieczności jego przesyłania. Przed wyłączeniem haseł należy potwierdzić działanie kluczy, aby uniknąć zablokowania dostępu do serwera.

Na własnym komputerze utwórz klucz, jeśli jeszcze go nie posiadasz:

ssh-keygen -t ed25519

Skopiuj część publiczną na serwer:

ssh-copy-id user@your-server

Następnie otwórz nową sesję SSH. Jeśli logowanie przebiegnie bez pytania o hasło, klucz działa poprawnie i można bezpiecznie wyłączyć hasła. Jeśli wystąpi błąd Permission denied (publickey), ten jeden błąd maskuje pięć różnych przyczyn, a dane wyjściowe ssh -v wskażą konkretny problem przed wprowadzeniem dalszych zmian. Jeśli klucze są nowością lub korzystasz z więcej niż jednego komputera, podstawy zarządzania kluczami SSH wyjaśniają pełny model: jeden klucz na urządzenie, uprawnienia wymagane przez sshd oraz sposób unieważnienia klucza w przypadku utraty laptopa.

Krok 2: Zabezpieczenie sshd za pomocą pliku typu drop-in

Nie należy edytować bezpośrednio pliku /etc/ssh/sshd_config. System Ubuntu 24.04 odczytuje pliki typu drop-in z lokalizacji /etc/ssh/sshd_config.d/. Mały plik w tym katalogu jest rozwiązaniem bardziej przejrzystym, przetrwa aktualizacje pakietów i jest łatwy do usunięcia w razie wystąpienia problemów. Nazwa pliku ma znaczenie: sshd zachowuje pierwszą odczytaną wartość dla każdego ustawienia, a obrazy chmurowe Ubuntu zawierają plik 50-cloud-init.conf z ustawieniem PasswordAuthentication yes w tym katalogu. Należy nazwać plik 00-, aby był sortowany przed wspomnianym plikiem i miał pierwszeństwo; plik 99- zostanie zignorowany bez komunikatu. Należy utworzyć plik:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Należy wkleić poniższą zawartość:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Każda linia zamyka kolejną furtkę. Ustawienie PasswordAuthentication no jest kluczowe: po wyłączeniu haseł atak typu brute-force staje się bezcelowy. Opcja KbdInteractiveAuthentication no zamyka drugą ścieżkę uwierzytelniania hasłem. Ustawienie PermitRootLogin no oznacza, że atakujący musi znać nazwę użytkownika i posiadać klucz, zamiast próbować atakować konto root, które istnieje na każdym serwerze.

Krok 3: Test konfiguracji i przeładowanie

Przed zastosowaniem zmian należy sprawdzić konfigurację pod kątem błędów, aby literówka nie spowodowała awarii usługi:

sudo sshd -t

sshd -t

Jeśli polecenie nie zwraca żadnych komunikatów, konfiguracja jest poprawna. Przeładuj SSH:

sudo systemctl reload ssh

systemctl reload sshd

Następnie sprawdź ustawienia, które faktycznie są używane przez sshd, aby wykryć, czy plik typu drop-in nie został nadpisany przez inny plik:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

sshd -T | grep -E 'passwordauthentication|pubkeyauthentication'

Oba polecenia powinny zwrócić no. Teraz, nie zamykając bieżącej sesji, otwórz nową w innym terminalu. Jeśli logowanie przy użyciu klucza przebiegnie pomyślnie, proces jest zakończony. W razie jakichkolwiek problemów pierwsza sesja pozostaje aktywna, co umożliwia naprawę konfiguracji. To nakładanie się sesji stanowi zabezpieczenie, którego nie należy pomijać.

Krok 4: Opcjonalny niestandardowy port

Przeniesienie SSH z portu 22 na inny, na przykład 2222, nie zwiększa bezpieczeństwa w rzeczywisty sposób, ponieważ zdeterminowany atakujący skanuje wszystkie porty. Działanie to jedynie redukuje szum w logach, gdyż większość zautomatyzowanych skanerów sprawdza wyłącznie port 22. Jeśli jest to wymagane, należy dodać Port 2222 do pliku typu drop-in, najpierw zezwolić na nowy port w zaporze sieciowej, a następnie wykonać sudo systemctl daemon-reload && sudo systemctl restart ssh.socket i połączyć się za pomocą ssh -p 2222. W systemie Ubuntu 24.04 to ssh.socket zarządza portem nasłuchiwania, więc zwykłe reload ssh pozostawia sshd na porcie 22; dopiero restart gniazda (socket) powoduje przejęcie nowego portu. Należy traktować to jako porządkowanie konfiguracji, a nie jako zabezpieczenie.

Krok 5: Dodatkowe warstwy zabezpieczeń

Zabezpieczone klucze SSH stanowią fundament, na którym opierają się dwie kolejne warstwy.

Fail2ban monitoruje logi i blokuje adresy IP, z których pochodzą powtarzające się nieudane próby logowania. Pozwala to wyeliminować szum generowany przez skanery i wcześnie odcinać intruzów. Narzędzie to naturalnie współpracuje z uwierzytelnianiem wyłącznie za pomocą kluczy: zobacz Fail2ban na Ubuntu w celu zatrzymania ataków SSH.

Jeszcze skuteczniejszym rozwiązaniem jest całkowite ukrycie SSH przed publicznym Internetem. Jeśli umieścisz SSH za VPN WireGuard i ograniczysz dostęp do portu 22 wyłącznie do tunelu, nikt spoza sieci VPN nie będzie w stanie nawiązać połączenia. Ataki typu brute-force stają się wtedy niemożliwe, a nie tylko trudne do przeprowadzenia. Wszystkie te działania zakładają istnienie domyślnej polityki blokowania ruchu w zaporze sieciowej, co opisano w konfiguracji UFW na VPS.

SSH to tylko jeden z punktów szerszej listy kontrolnej: pierwsze 10 minut na nowym VPS porządkuje te kroki, a automatyczne aktualizacje zabezpieczeń na Ubuntu dbają o późniejsze łatanie systemu. Zaryglowanie drzwi nie chroni jednak usług działających wewnątrz. Jeśli ten sam VPS obsługuje menedżer haseł, utwardzenie konfiguracji Vaultwarden zabezpiecza dwa elementy, których uwierzytelnianie kluczem nie obejmuje: token administratora oraz plik kopii zapasowej.

FAQ

Jak wyłączyć logowanie hasłem przez SSH w Ubuntu 24.04?

Utwórz plik konfiguracyjny w /etc/ssh/sshd_config.d/00-hardening.conf (prefiks 00 sprawia, że jest on wczytywany przed 50-cloud-init.conf, którego PasswordAuthentication yes miałoby pierwszeństwo, ponieważ sshd zachowuje pierwszą napotkaną wartość), zawierający PasswordAuthentication no oraz KbdInteractiveAuthentication no. Uruchom sudo sshd -t, aby sprawdzić poprawność składni, a następnie sudo systemctl reload ssh. Przed zakończeniem sesji upewnij się w nowym oknie terminala, że logowanie kluczem działa poprawnie. Edycja osobnego pliku zamiast sshd_config pozwala zachować zmiany po aktualizacji pakietów i ułatwia ich wycofanie.

Czy należy wyłączyć logowanie na konto root przez SSH?

Tak. Ustaw PermitRootLogin no, aby uniemożliwić bezpośrednie logowanie na konto root. Loguj się jako zwykły użytkownik i używaj sudo do zadań administracyjnych. Konto root istnieje w każdym systemie Linux, więc pozostawienie go dostępnym daje atakującemu gotową nazwę użytkownika do ataku. Wyłączenie tej opcji wymusza na atakującym konieczność poznania nazwy Twojego konta oraz posiadania klucza prywatnego.

Czy zmiana portu SSH zwiększa bezpieczeństwo serwera?

Nie w znaczącym stopniu. Przeniesienie usługi z portu 22 ukrywa ją przed prostymi skanerami, które sprawdzają tylko domyślny port, co redukuje liczbę wpisów w logach, ale rzeczywisty atakujący przeskanuje wszystkie porty i znajdzie usługę. To uwierzytelnianie wyłącznie za pomocą kluczy faktycznie powstrzymuje włamania. Jeśli zmieniasz port, najpierw otwórz nowy port w zaporze sieciowej, a następnie uruchom sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; w Ubuntu 24.04 gniazdo zarządza procesem nasłuchującym, a zwykłe przeładowanie usługi pozostawi sshd na porcie 22.

Czy potrzebuję Fail2ban, jeśli używam kluczy SSH?

Jest to opcjonalne, ale nadal przydatne. Przy uwierzytelnianiu wyłącznie kluczem, zgadywanie haseł nie może się powieść, więc Fail2ban nie jest głównym zabezpieczeniem przed włamaniem. Ogranicza on jednak liczbę nieudanych prób z jednego adresu, co zmniejsza szum w logach i wcześnie blokuje powtarzające się próby; powolny, rozproszony atak i tak pozostanie poniżej progu blokady. Używaj go jako dodatkowej warstwy zabezpieczeń, a najlepiej utrzymuj dostęp do SSH za pośrednictwem VPN.

Jak odzyskać dostęp, jeśli zablokuję sobie SSH?

Użyj konsoli internetowej dostarczonej przez dostawcę serwera, która łączy się z maszyną przez połączenie szeregowe lub VNC, z pominięciem SSH. Z tego poziomu możesz się zalogować, poprawić plik konfiguracyjny w sshd i przeładować usługę. Właśnie dlatego nową konfigurację SSH należy testować w drugim terminalu przed zamknięciem pierwszej sesji oraz upewnić się, że logowanie kluczem działa poprawnie przed wyłączeniem haseł.