Jak zabezpieczyć SSH na VPS

Dlaczego SSH jest priorytetem w procesie hardeningu

SSH służy do zdalnego zarządzania serwerem, co czyni go głównym celem ataków. Po uruchomieniu instancji VPS skanery sieciowe natychmiast rozpoczynają próby odgadnięcia nazw użytkowników i haseł na porcie 22. Proces ten jest widoczny w logach systemowych już po kilku minutach. Hardening usługi SSH polega na wyeliminowaniu metod podatnych na ataki typu brute-force: należy całkowicie wyłączyć logowanie za pomocą hasła, wyłączyć logowanie na konto root oraz zezwolić na dostęp wyłącznie za pomocą kluczy kryptograficznych. Po wprowadzeniu tych zmian ataki typu brute-force stają się nieskuteczne, ponieważ nie istnieje hasło, które można by odgadnąć.

Powyższe kroki wymagają posiadania działającej usługi SSH. Jeśli logowanie jest możliwe, można przystąpić do hardeningu. Należy wykonywać kroki w podanej kolejności. Zaleca się utrzymywanie aktywnej sesji bieżącej do czasu potwierdzenia poprawnego działania nowej sesji, aby uniknąć ryzyka utraty dostępu do serwera w przypadku błędu w konfiguracji.

Krok 1: Najpierw należy upewnić się, że uwierzytelnianie kluczami działa poprawnie

Uwierzytelnianie kluczami zastępuje hasło parą kluczy: kluczem prywatnym, który pozostaje na komputerze, oraz kluczem publicznym, który umieszcza się na serwerze. Serwer weryfikuje posiadanie klucza prywatnego bez konieczności przesyłania go poza maszynę lokalną. Przed wyłączeniem logowania hasłem należy potwierdzić działanie kluczy, aby uniknąć utraty dostępu do systemu.

Jeśli nie posiadasz kluczy, należy utworzyć nowy na własnym komputerze:

ssh-keygen -t ed25519

Należy skopiować część publiczną na serwer:

ssh-copy-id user@your-server

Następnie należy otworzyć nową sesję SSH. Jeśli logowanie następuje bez żądania hasła, klucze działają poprawnie i można bezpiecznie wyłączyć logowanie hasłem. Jeśli temat kluczy SSH jest nowy lub korzystasz z wielu komputerów, podstawy zarządzania kluczami SSH wyjaśnia pełny model: jeden klucz na urządzenie, wymagane uprawnienia dla procesu sshd oraz procedurę unieważniania klucza w przypadku zgubienia laptopa.

Step 2: Utwardzenie sshd za pomocą pliku drop-in

Nie należy edytować /etc/ssh/sshd_config bezpośrednio. Ubuntu 24.04 odczytuje pliki drop-in z /etc/ssh/sshd_config.d/. Mały plik w tej lokalizacji jest rozwiązaniem czystszym, zachowuje zmiany podczas aktualizacji pakietów i jest łatwy do usunięcia w przypadku wystąpienia problemów. Nazwa ma znaczenie: sshd zachowuje pierwszą odczytaną wartość dla każdego ustawienia, a obrazy Ubuntu cloud zawierają 50-cloud-init.conf z PasswordAuthentication yes w tym katalogu. Nazwij swój plik 00-, aby został posortowany przed tamtym plikiem i nadpisał jego ustawienia; plik 99- zostanie pominięty bez powiadomienia. Utwórz plik:

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

Umieść treść w:

# 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 ogranicza wektor ataku. PasswordAuthentication no jest kluczowa: po wyłączeniu haseł ataki typu brute-force stają się bezskuteczne. KbdInteractiveAuthentication no blokuje drugą ścieżkę uwierzytelniania opartą na haśle. PermitRootLogin no oznacza, że napastnik musi znać nazwę użytkownika i posiadać klucz, zamiast atakować jedyne konto, root, które istnieje w każdym systemie.

Step 3: Test the config, then reload

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

Jeśli polecenie nie wyświetli żadnego komunikatu, konfiguracja jest poprawna. Należy przeładować usługę SSH:

sudo systemctl reload ssh

Następnie należy sprawdzić ustawienia faktycznie używane przez sshd, aby upewnić się, że plik konfiguracyjny nie został nadpisany przez inny plik:

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

Oba polecenia powinny zwrócić no. Następnie, nie zamykając bieżącej sesji, należy otworzyć nową sesję w innym terminalu. Jeśli logowanie przy użyciu klucza przebiegnie pomyślnie, proces został zakończony. W przypadku wystąpienia błędów, pierwsza sesja pozostaje aktywna w celu dokonania naprawy. Takie podejście zapewnia bezpieczeństwo, dlatego nie należy pomijać tego kroku.

Step 4: Opcjonalny niestandardowy port

Zmiana portu SSH z 22 na 2222 nie zwiększa realnego poziomu bezpieczeństwa, ponieważ zdeterminowany atakujący skanuje wszystkie porty. Zmiana ta redukuje liczbę wpisów w logach, ponieważ większość zautomatyzowanych skanerów sprawdza tylko port 22. Jeśli chcą Państwo dokonać tej zmiany, należy dodać Port 2222 do pliku konfiguracyjnego, najpierw odblokować nowy port w firewallu, a następnie uruchomić sudo systemctl daemon-reload && sudo systemctl restart ssh.socket i połączyć się za pomocą ssh -p 2222. W systemie Ubuntu 24.04 port nasłuchiwania jest zarządzany przez ssh.socket, zatem standardowe polecenie reload ssh pozostawia sshd na porcie 22; nowa konfiguracja portu zostanie załadowana dopiero po ponownym uruchomieniu gniazda (socket). Należy traktować tę czynność jako element porządkowania konfiguracji, a nie metodę ochrony.

Krok 5: Dodatkowe warstwy zabezpieczeń

Użycie wzmocnionych kluczy SSH stanowi fundament, na którym budowane są kolejne dwie warstwy ochrony.

Fail2ban monitoruje logi i blokuje adresy generujące powtarzające się błędy. Pozwala to ograniczyć szum generowany przez skanery i wcześnie eliminuje intruzów. Narzędzie to współpracuje z metodą uwierzytelniania wyłącznie za pomocą kluczy: zobacz Fail2ban na Ubuntu w celu zatrzymania ataków SSH.

Najskuteczniejszą metodą jest całkowite odcięcie usługi SSH od publicznego internetu. Jeśli umieścisz SSH za VPN WireGuard i skonfigurujesz firewall, aby port 22 był dostępny tylko przez tunel, nikt spoza sieci VPN nie uzyska do niego dostępu. W takim przypadku ataki typu brute-force stają się niemożliwe, a nie tylko utrudnione. Wszystkie powyższe działania wymagają domyślnej polityki blokowania ruchu (default-deny) w firewallu, czyli konfiguracji UFW na VPS.

SSH to tylko jeden element szerszej listy kontrolnej: pierwsze 10 minut na nowym VPS przedstawia kroki w odpowiedniej kolejności, a automatyczne aktualizacje bezpieczeństwa na Ubuntu zapewniają późniejsze łatanie systemu.

FAQ

Jak wyłączyć logowanie za pomocą hasła dla SSH na Ubuntu 24.04?

Należy utworzyć plik drop-in w /etc/ssh/sshd_config.d/00-hardening.conf (prefiks 00 sprawia, że plik jest sortowany przed 50-cloud-init.conf, którego wartość PasswordAuthentication yes zostałaby wygrana, ponieważ sshd przyjmuje pierwszą odczytaną wartość) zawierający PasswordAuthentication no oraz KbdInteractiveAuthentication no. Należy uruchomić sudo sshd -t w celu weryfikacji, a następnie sudo systemctl reload ssh. Przed przejściem na logowanie kluczem należy potwierdzić jego działanie w nowej sesji. Edycja pliku drop-in zamiast sshd_config pozwala zachować zmiany podczas aktualizacji pakietów i ułatwia wycofanie zmian.

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

Tak. Należy ustawić PermitRootLogin no, aby uniemożliwić bezpośrednie logowanie na konto root. Należy logować się jako zwykły użytkownik i używać sudo do zadań administracyjnych. Konto root istnieje w każdym systemie Linux, więc pozostawienie go dostępnym daje napastnikowi znaną nazwę użytkownika do ataku. Wyłączenie logowania root wymaga od napastnika znajomości nazwy konta oraz posiadania klucza.

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

Nie ma to znaczenia dla poziomu bezpieczeństwa. Zmiana portu 22 ukrywa serwer przed prostymi skanerami sprawdzającymi tylko port 22, co redukuje szum w logach, jednak profesjonalny napastnik i tak przeskanuje wszystkie porty. Autoryzacja wyłącznie za pomocą kluczy jest skuteczną metodą ochrony przed włamaniem. Po zmianie portu należy najpierw otworzyć nowy port w firewallu, a następnie uruchomić sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; w systemie Ubuntu 24.04 proces socket zarządza nasłuchiwaniem, więc zwykłe przeładowanie nie zmieni portu sshd na 22.

Czy Fail2ban jest wymagany przy użyciu kluczy SSH?

Jest to opcjonalne, ale nadal przydatne. Przy autoryzacji wyłącznie kluczami zgadywanie haseł nie może zakończyć się sukcesem, więc Fail2ban nie jest głównym mechanizmem obronnym. Narzędzie to ogranicza liczbę prób logowania z jednego adresu, co redukuje szum skanerów w logach i szybko blokuje powtarzające się próby; powolne, rozproszone ataki i tak pozostają poniżej progu blokady. Zaleca się uruchomienie Fail2ban przy autoryzacji kluczem oraz umieszczenie SSH za VPN.

Jak odzyskać dostęp, jeśli zostanie się zablokowanym w SSH?

Należy użyć konsoli webowej dostawcy, która łączy się z serwerem przez połączenie szeregowe lub VNC, które nie korzysta z protokołu SSH. Za jej pomocą można się zalogować, naprawić plik drop-in sshd i przeładować usługę. Właśnie dlatego należy testować nową konfigurację SSH w drugiej sesji terminala przed zamknięciem pierwszej oraz dlaczego autoryzacja kluczem powinna działać przed wyłączeniem haseł.