Jak zabezpieczyć SSH na VPS z Linuksem: lista kontrolna

1. Zaktualizuj system i włącz automatyczne aktualizacje bezpieczeństwa

Najpierw zainstaluj oczekujące aktualizacje: apt update odświeża listy pakietów, a apt upgrade instaluje nowsze wersje zainstalowanych pakietów. [1]

sudo apt update
sudo apt upgrade

W Ubuntu aktualizacje bezpieczeństwa instalują się automatycznie dzięki pakietowi unattended-upgrades, który jest domyślnie zainstalowany i uruchamiany raz dziennie. Obie wartości w pliku /etc/apt/apt.conf.d/20auto-upgrades powinny wynosić „1”, a próbne uruchomienie pokaże, co zostałoby zainstalowane. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Program nie uruchamia jednak serwera ponownie, bo opcja Unattended-Upgrade::Automatic-Reboot ma domyślnie wartość false – gdy aktualizacja wymaga restartu, zrestartuj serwer ręcznie. [1] Jeśli w Debianie 12 brakuje pakietu lub pliku, zainstaluj unattended-upgrades i utwórz plik z dwoma powyższymi wierszami.

2. Utwórz zwykłego użytkownika z uprawnieniami sudo

Zadania administracyjne wykonuj na własnym koncie użytkownika za pomocą sudo, które pyta o hasło tego użytkownika, a nie o hasło roota. Członkowie grupy sudo uzyskują w ten sposób pełne uprawnienia roota. [2]

sudo adduser deploy
sudo adduser deploy sudo

adduser poprosi o hasło i kilka nieobowiązkowych informacji. [2] Ustaw długie hasło: SSH będzie korzystać z kluczy, ale sudo nadal będzie o nie pytać. Następnie sprawdź konto – polecenie sudo whoami powinno wyświetlić „root”.

su - deploy
sudo whoami

Jeśli w Debianie 12 nie ma polecenia sudo, najpierw zainstaluj je jako root poleceniem apt install sudo.

3. Wygeneruj klucz ed25519 na swoim komputerze

Parę kluczy utwórz na własnym komputerze, a nie na serwerze. Ubuntu zaleca typ ed25519 ze względu na krótsze klucze i mniejsze obciążenie obliczeniowe, a ssh-keygen poprosi o hasło (passphrase), które chroni klucz prywatny. [3]

ssh-keygen -t ed25519

Zostaw domyślną nazwę pliku. Klucz prywatny to ~/.ssh/id_ed25519, a klucz publiczny, który kopiujesz na serwery, to ~/.ssh/id_ed25519.pub. [3]

W systemie Windows uruchom to samo polecenie w oknie PowerShell – para kluczy trafi do folderu .ssh w twoim profilu użytkownika. Microsoft odradza pozostawianie pustego hasła do klucza i ostrzega, że każdy, kto zdobędzie klucz prywatny, może zalogować się jako ty. [4]

ssh-keygen -t ed25519

4. Skopiuj klucz publiczny na serwer

W systemach Linux i macOS polecenie ssh-copy-id dopisuje twój klucz publiczny do pliku ~/.ssh/authorized_keys danego użytkownika na serwerze. [3]

ssh-copy-id deploy@203.0.113.10

W poradniku Microsoftu klucze kopiuje się inaczej: przez PowerShell albo za pomocą scp. [4] W przypadku serwera z Linuksem poniższe polecenie dopisze twój klucz i ustawi uprawnienia tak, aby zapisywać w katalogu i w pliku mogło tylko twoje konto:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

sshd sprawdza te uprawnienia, zanim przyjmie logowanie – odpowiada za to opcja StrictModes, domyślnie włączona. [5] Następnie w nowym terminalu uruchom ssh deploy@203.0.113.10: logowanie powinno się udać bez podawania hasła konta. Jeśli się nie uda, spróbuj ponownie, śledząc na bieżąco log SSH na serwerze: [3]

sudo journalctl -fu ssh.service

5. Zapisz ustawienia w pliku drop-in

W Ubuntu plik /etc/ssh/sshd_config zaczyna się od wiersza Include /etc/ssh/sshd_config.d/*.conf, a OpenSSH w przypadku większości ustawień zachowuje pierwszą wczytaną wartość, więc pliki z tego katalogu mają pierwszeństwo przed plikiem głównym. [3] Dołączane pliki są wczytywane w kolejności leksykograficznej, a dla każdej opcji obowiązuje pierwsza wartość, jaką odczyta sshd, [5] dlatego nazwij swój plik 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

Według dokumentacji sshd_config te opcje działają następująco:

• PermitRootLogin no blokuje logowanie na konto root przez SSH. Wartość domyślna, prohibit-password, odrzuca hasła dla roota, ale nadal przyjmuje klucze. [5]
• PasswordAuthentication no wyłącza logowanie hasłem, które domyślnie jest dozwolone. [5]
• KbdInteractiveAuthentication no wyłącza metodę keyboard-interactive – osobny sposób logowania, również domyślnie włączony; dawniej ta opcja nazywała się ChallengeResponseAuthentication. [5]
• AllowUsers deploy (opcjonalnie) pozwala logować się tylko wymienionym użytkownikom. W odróżnieniu od większości opcji każdy kolejny wiersz AllowUsers rozszerza listę. [5] Wpisz nazwę bezbłędnie, inaczej nikt się nie zaloguje.

Od teraz traktuj konto z sudo tak jak konto root: według dokumentacji pakietu openssh w Ubuntu każde konto, z którego można uzyskać uprawnienia roota, jest z punktu widzenia ataków z zewnątrz równoważne kontu root. [6] W Debianie 12 najpierw sprawdź poleceniem grep -n Include /etc/ssh/sshd_config, czy plik zawiera wiersz Include.

6. Sprawdź, czy żaden plik nie włącza z powrotem logowania hasłem

Skoro obowiązuje pierwsza wartość, każdy plik, który w kolejności sortowania znajdzie się przed twoim, ma pierwszeństwo. Przeszukaj katalog:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

W obrazach chmurowych cloud-init zapisuje zarządzane przez siebie ustawienia SSH w pliku /etc/ssh/sshd_config.d/50-cloud-init.conf, o ile sshd_config dołącza ten katalog. [7] Jeśli ten plik zawiera PasswordAuthentication yes, ma pierwszeństwo przed każdym plikiem, który znajdzie się po nim w kolejności sortowania – właśnie dlatego nazwa twojego pliku zaczyna się od 00. Zmień tam wartość również na no, żeby pliki były ze sobą zgodne.

7. Sprawdź konfigurację i uruchom ponownie SSH

Przed restartem sprawdź pliki: błędne ustawienie może sprawić, że sshd się nie uruchomi, a SSH może być twoją jedyną drogą dostępu do serwera. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Najpierw popraw wszystko, co zgłosi sshd -t. Po restarcie nie zamykaj bieżącej sesji i sprawdź logowanie z drugiego terminala:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

Pierwsze logowanie powinno się udać, a drugie zostać odrzucone. Jeśli logowanie na twoje konto się nie powiedzie, cofnij zmianę w otwartej sesji i sprawdź log SSH tak jak w kroku 4. [3]

8. Zmień port w Ubuntu 24.04 (opcjonalnie)

W Ubuntu 24.04 na porcie 22 nasłuchuje ssh.socket, korzystając z mechanizmu aktywacji gniazd systemd (socket activation). Generator systemd zamienia wiersze Port z pliku sshd_config i jego plików drop-in na ustawienia gniazda, dlatego po zmianie portu trzeba przeładować konfigurację systemd i uruchomić ponownie ssh.socket. [6]

sshd akceptuje więcej niż jeden wiersz Port, [5] więc na czas testowania nowego portu zostaw też port 22:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Sprawdź nowy port z drugiego terminala. Potem usuń wiersz Port 22, powtórz te trzy polecenia i w krokach 9 i 10 używaj portu 2222.

ssh -p 2222 deploy@203.0.113.10

W Debianie 12 najpierw sprawdź, czy gniazdo jest używane. Jeśli jest nieaktywne, zmiana zacznie obowiązywać po ponownym uruchomieniu usługi.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Odblokuj SSH w UFW, a potem włącz zaporę

Zapora UFW jest po instalacji wyłączona, a po włączeniu domyślnie odrzuca ruch przychodzący. Jej dokumentacja ostrzega, że ufw enable może zerwać połączenia SSH, więc najpierw dodaj regułę dla SSH. [8]

Dla SSH użyj reguły limit zamiast allow. Reguła limit nadal przepuszcza połączenia, ale blokuje adres, który w ciągu 30 sekund spróbuje otworzyć 6 lub więcej połączeń. Nie dodawaj obu reguł, bo UFW stosuje pierwszą pasującą regułę. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Gdy włączasz UFW przez SSH, program prosi o potwierdzenie. [8] Po zmianie portu SSH ustaw regułę limit dla 2222/tcp zamiast dla portu 22. Jeśli w Debianie 12 nie ma polecenia ufw, najpierw zainstaluj UFW. Jeśli w ogóle nie chcesz wystawiać SSH do publicznego internetu, łącz się z nim wyłącznie przez prywatną sieć WireGuard. Ochronę wykraczającą poza sam serwer opisuje nasza lista kontrolna ochrony VPS przed atakami DDoS.

10. Włącz Fail2ban dla sshd

W Ubuntu 24.04 pakiet zawiera plik /etc/fail2ban/jail.d/defaults-debian.conf, który włącza jail sshd, ustawia backend = systemd i blokuje adresy przez nftables. [9] Backend systemd odczytuje dziennik systemd (journal), więc jail nie potrzebuje osobnego pliku logu. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

Domyślny plik jail.conf dostarczany z Fail2ban blokuje adres na 10 minut po 5 nieudanych próbach w ciągu 10 minut i zaznacza, że tego pliku nie należy edytować – swoje zmiany zapisz w jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Zastąp 198.51.100.7 swoim stałym adresem albo usuń ten adres. Standardowy jail używa port = ssh, więc po zmianie portu SSH dodaj port = 2222. [10] W Debianie 12 zostaw tu backend = systemd i zainstaluj python3-systemd – bibliotekę Pythona do obsługi systemd, z której korzysta ten backend. [10] Następnie uruchom ponownie Fail2ban i sprawdź, czy działa:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Sprawdź, co jeszcze nasłuchuje

Każdy otwarty port to kolejna furtka do serwera. UFW potrafi wyświetlić wszystkie nasłuchujące porty TCP i otwarte porty UDP, a przy każdym z nich adres (* oznacza wszystkie interfejsy), program, który go obsługuje, i reguły, które go dotyczą. [8]

sudo ufw show listening

Usługa nasłuchująca na adresie 127.0.0.1 jest dostępna tylko z samego serwera. Niepotrzebne usługi dostępne z zewnątrz wyłącz poleceniem systemctl disable --now – tak samo w dokumentacji pakietu openssh w Ubuntu wyłącza się ssh.socket. [6]

sudo systemctl disable --now SERVICE_NAME