Zabezpieczenie nowego VPS: lista kontrolna krok po kroku

Przejdziesz przez listę kontrolną, która zamienia nowy VPS w bezpieczny serwer: aktualizacje, silne hasła, własny użytkownik, klucz SSH, firewall, fail2ban i automatyczne poprawki bezpieczeństwa. Przy każdym kroku wyjaśniamy, po co go robić i co dokładnie ustawiasz.

Dlaczego zaraz po utworzeniu#

Każdy publiczny adres IP jest widoczny z całego internetu. Automatyczne boty skanują adresy i próbują logować się przez SSH popularnymi nazwami i hasłami. Na nowym VPS pierwsze próby zobaczysz często w ciągu kilku minut. Sprawdź:

journalctl -u ssh --since "1 hour ago" | grep -E "Failed password|Invalid user"

• journalctl -u ssh – wypisuje wpisy usługi SSH.
• --since "1 hour ago" – tylko z ostatniej godziny.
• grep -E "…" – zostawia tylko linie z nieudanym logowaniem lub nieistniejącym użytkownikiem.

Znane skanery internetu blokujemy w sieci, ale to nie zatrzymuje każdej próby. Przed resztą chronią silne hasło, klucz SSH i fail2ban.

Lista kontrolna#

Bezpieczeństwo a strefa klienta#

Zakładki Pliki i Baza danych w strefie klienta łączą się z VPS przez SSH, używając nazwy użytkownika i hasła (domyślnie root i hasło z chwili utworzenia VPS). Niektóre kroki tego poradnika mają więc na nie wpływ:

Dane logowania w zakładce Pliki może zmienić tylko właściciel usługi. Konsola oraz zakładki Sieć, Firewall, Kopie zapasowe i Zmiana pakietu działają zawsze; ustawienia VPS nie mają na nie wpływu. Zdecyduj, co jest dla Ciebie ważniejsze. Wyłączenie logowania hasłem daje najwyższe bezpieczeństwo. Jeśli używasz zakładek Pliki i Baza danych, zostaw hasło włączone, ale silne, i zainstaluj fail2ban.

Aktualizacja systemu#

1. Pobierz listę dostępnych aktualizacji:

   apt update

   • apt update – wczytuje listę nowych wersji pakietów z repozytoriów. Sam niczego nie instaluje.

2. Zainstaluj wszystkie aktualizacje:

   apt full-upgrade -y

   • apt full-upgrade – aktualizuje pakiety i może przy tym dodać lub usunąć zależności (na przykład nowe jądro).
   • -y – automatycznie odpowiada „tak” na potwierdzenie.

3. Jeśli instalacja zapyta o plik konfiguracyjny (na przykład /etc/ssh/sshd_config „has been locally modified”), wybierz keep the local version currently installed. Zachowasz w ten sposób obecne ustawienia, z którymi VPS działa.

4. Sprawdź, czy potrzebny jest restart:

   ls /var/run/reboot-required

   Jeśli polecenie znajdzie plik, zrestartuj. Na Debianie bez pakietu unattended-upgrades plik może nie powstać, więc tam restartuj zawsze po aktualizacji jądra (pakiet zaczynający się od linux-image).

5. Zrestartuj VPS:

   reboot

   Połączenie SSH się zamknie. Połącz się ponownie po około minucie.

Zmiana hasła root#

Hasło z chwili utworzenia VPS było widoczne w strefie klienta albo w e-mailu. Ustaw nowe, które znasz tylko Ty.

1. Wygeneruj silne hasło, na przykład generatorem haseł (co najmniej 20 znaków), i zapisz je w menedżerze haseł.

2. Rozpocznij zmianę hasła:

   passwd

   • passwd – bez innych parametrów zmienia hasło użytkownika, który uruchamia polecenie (czyli roota).

3. Przy monicie New password: wklej nowe hasło i naciśnij Enter. Hasło się nie wyświetla.

4. Przy monicie Retype new password: wklej je ponownie. Zobaczysz passwd: password updated successfully.

5. Nie zamykaj bieżącego okna. Otwórz nowe i przetestuj logowanie nowym hasłem.

6. W strefie klienta otwórz zakładkę Pliki, kliknij Zmień dane logowania, wypełnij Użytkownik root, Port 22 i nowe Hasło i kliknij Zweryfikuj i zapisz.

Nowy użytkownik z sudo#

Jako root każda literówka w poleceniu dotyka całego systemu. Do codziennej pracy utwórz własnego użytkownika, który prosi o uprawnienia administratora tylko poleceniem sudo. Dla przykładu użyjemy nazwy jan.

1. Utwórz użytkownika:

   adduser jan

   • adduser – tworzy użytkownika i jego folder domowy /home/jan oraz pyta o hasło.

   Wpisz hasło dwa razy (inne niż hasło root). Pytania o imię, telefon i inne dane pomiń klawiszem Enter i na końcu potwierdź Y.

2. Dodaj użytkownika do grupy sudo:

   usermod -aG sudo jan

   • usermod – zmienia właściwości użytkownika.
   • -aG sudo – dodaje (-a) użytkownika do dodatkowej grupy (-G) sudo. Bez -a użytkownik wypadłby ze wszystkich pozostałych grup.
   • Członkowie grupy sudo mogą wykonywać polecenia jako root.

3. Jeśli masz już klucz SSH dla roota, skopiuj go także nowemu użytkownikowi:

   install -d -m 700 -o jan -g jan /home/jan/.ssh
   install -m 600 -o jan -g jan /root/.ssh/authorized_keys /home/jan/.ssh/authorized_keys

   • install -d – tworzy folder .ssh.
   • -m 700 / -m 600 – uprawnienia: folder tylko dla właściciela, plik do odczytu i zapisu tylko dla właściciela. Inne uprawnienia SSH odrzuca.
   • -o jan -g jan – właścicielem będzie użytkownik jan.

4. W nowym oknie zaloguj się jako nowy użytkownik i przetestuj sudo:

   ssh [email protected]
   sudo whoami

   • sudo whoami – wykonuje polecenie whoami jako root. Po wpisaniu hasła użytkownika jan musi wypisać root.

Jeśli brakuje polecenia adduser lub sudo (minimalna instalacja Debiana), zainstaluj je: apt install adduser sudo.

Klucz SSH i wyłączenie logowania hasłem#

To najważniejszy krok. Hasło da się zgadnąć; klucza SSH praktycznie nie. Kroki dla Windows, macOS i Linux są w osobnym poradniku Klucz SSH: logowanie bez hasła, łącznie z bezpiecznym wyłączeniem logowania hasłem.

Zakaz logowania roota#

Gdy root nie może logować się przez SSH, atakujący musi znać także nazwę Twojego użytkownika. Zrób to dopiero wtedy, gdy możesz zalogować się jako nowy użytkownik i sudo działa.

1. Otwórz (lub utwórz) własny plik konfiguracyjny serwera SSH:

   nano /etc/ssh/sshd_config.d/00-zabezpeceni.conf

2. Dodaj linię:

   PermitRootLogin no

   Ustawienie	Co robi	Zalecana wartość	Kiedy zmieniać
   PermitRootLogin	Czy root może logować się przez SSH. no = wcale, prohibit-password = tylko kluczem, yes = także hasłem.	no	prohibit-password, jeśli potrzebujesz dostępu roota kluczem (na przykład dla skryptu kopii zapasowych).

   Nazwa pliku zaczyna się od 00, aby wczytywał się pierwszy. Serwer SSH używa pierwszej znalezionej wartości każdego ustawienia.

3. Sprawdź konfigurację i obowiązującą wartość:

   sshd -t && sshd -T | grep -i permitrootlogin

   • sshd -t – kontrola składni. Przy błędzie wypisuje plik i linię.
   • && – następne polecenie uruchamia się tylko wtedy, gdy poprzednie zakończyło się bez błędu.
   • sshd -T – wypisuje wynikową obowiązującą konfigurację. Musi zawierać permitrootlogin no.

4. Zrestartuj serwer SSH:

   systemctl restart ssh

   Bieżące połączenie pozostaje otwarte.

5. W nowym oknie sprawdź, że ssh [email protected] już nie loguje, a ssh [email protected] tak.

Jako root pracujesz potem przez sudo -i (otwiera wiersz poleceń roota po wpisaniu hasła użytkownika jan).

Zmiana portu SSH#

Przeniesienie SSH z portu 22 na inny nie jest prawdziwym zabezpieczeniem; atakujący nowy port znajdzie. Znacznie ogranicza jednak próby botów w logu.

Zalety:

• Mniej automatycznych prób logowania i czystsze logi.

Wady:

• Przy każdym połączeniu musisz podać port (ssh -p 2222 …).
• Niektóre sieci firmowe i publiczne blokują niestandardowe porty.
• Port trzeba zaktualizować w firewallu, w fail2ban i w strefie klienta (Pliki).

Jeśli zdecydujesz się na zmianę, wybierz port powyżej 1024, którego nie używa żadna inna aplikacja (unikaj na przykład portu 2022, którego niektóre panele gier używają do SFTP). W przykładzie użyjemy 2222.

1. Zezwól na nowy port w firewallu, zanim przeniesiesz SSH: w zakładce Firewall dodaj regułę Przychodzący, Zezwól, TCP dla portu 2222 (wymagana w trybie Blokuj wszystko poza dozwolonym, nieszkodliwa w trybie Zezwól na wszystko), a jeśli używasz UFW, uruchom ufw allow 2222/tcp.

2. Dodaj dwie linie do pliku /etc/ssh/sshd_config.d/00-zabezpeceni.conf. Stary port na razie zostaw, aby zmiana Cię nie odcięła:

   Port 22
   Port 2222

   • Port – port, na którym nasłuchuje serwer SSH. Linii Port może być kilka; serwer nasłuchuje wtedy na wszystkich.

3. Sprawdź konfigurację: sshd -t.

4. Sprawdź, jak SSH startuje na Twoim VPS:

   systemctl is-active ssh.socket

   Wynik active oznacza, że systemd uruchamia SSH przez socket (domyślnie na Ubuntu 24.04). Wynik inactive oznacza zwykłą usługę (zwykle Debian 13).

Zastosuj nowy port zgodnie z wynikiem:

5. Sprawdź, czy SSH nasłuchuje na obu portach: ss -tlnp | grep -E ':22 |:2222 '.
6. W nowym oknie połącz się przez nowy port: ssh -p 2222 [email protected].
7. Gdy połączenie przez nowy port działa, usuń z konfiguracji linię Port 22.
8. Sprawdź konfigurację: sshd -t.
9. Wczytaj zmianę tym samym poleceniem co wyżej (zależnie od tego, czy socket jest aktywny).
10. W strefie klienta otwórz Pliki › Zmień dane logowania i wpisz port 2222. Zakładki Pliki i Baza danych łączą się z VPS przez SSH i bez nowego portu przestałyby działać.
11. Zaktualizuj port w jailu sshd w fail2ban (zobacz Fail2ban).
12. Usuń regułę dla portu 22 w firewallu.

Firewall i fail2ban#

• Firewall w strefie klienta filtruje ruch, zanim dotrze do VPS, i konfigurujesz go klikaniem: Firewall w strefie klienta.
• UFW to firewall bezpośrednio wewnątrz VPS: Firewall UFW.
• Fail2ban obserwuje nieudane logowania i blokuje atakujących: Fail2ban.

Jeden firewall wystarczy. Początkującym zalecamy firewall w strefie klienta, bo naprawisz go, nawet jeśli się odetniesz.

Automatyczne aktualizacje bezpieczeństwa#

Pakiet unattended-upgrades instaluje aktualizacje bezpieczeństwa raz dziennie. Na Ubuntu jest zainstalowany i włączony; na Debianie włączasz go sam.

Domyślnie Ubuntu instaluje tylko aktualizacje bezpieczeństwa; Debian aktualizacje bezpieczeństwa i poprawki z wydań punktowych wersji stabilnej (na przykład 13.1, 13.2). VPS nie restartuje się sam. Zachowanie zmieniasz we własnym pliku, który nadpisuje domyślny 50unattended-upgrades (tamtego nie edytuj; aktualizacja pakietu mogłaby go nadpisać):

nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Wypróbuj ustawienia na sucho:

unattended-upgrade --dry-run --debug

• --dry-run – tylko symulacja; nic nie jest instalowane.
• --debug – szczegółowe wyjście, łącznie z wczytanymi ustawieniami i pakietami, które zostałyby zaktualizowane.

Zapisy rzeczywistych aktualizacji są w folderze /var/log/unattended-upgrades/.

Strefa czasowa i nazwa serwera#

1. Ustaw strefę czasową, aby czasy w logach się zgadzały (przykład używa czasu środkowoeuropejskiego):

   timedatectl set-timezone Europe/Prague

   • timedatectl – ustawia czas systemowy i strefę czasową.
   • set-timezone Europe/Prague – czas środkowoeuropejski, łącznie z czasem letnim (dla Polski możesz użyć Europe/Warsaw, ta sama strefa).

2. Sprawdź wynik przez timedatectl. Linia Time zone musi pokazywać Europe/Prague, a System clock synchronized: yes.

3. Opcjonalnie zmień nazwę serwera (hostname):

   hostnamectl set-hostname vps1

   • hostnamectl set-hostname vps1 – ustawia nazwę VPS na vps1. Używaj małych liter, cyfr i myślników.

   Nowa nazwa pokaże się w znaku zachęty po ponownym zalogowaniu. Jeśli sudo zacznie wypisywać unable to resolve host vps1, dodaj nazwę do /etc/hosts w linii 127.0.1.1. Jeśli nagłówek pliku mówi, że jest generowany automatycznie, postępuj według instrukcji w nagłówku.

Co dalej#

• Kopie zapasowe: archiwizujemy cały VPS i możesz go przywrócić w zakładce Kopie zapasowe. Ważne dane archiwizuj także poza VPS, zobacz Kopie zapasowe VPS.
• Przegląd: od czasu do czasu sprawdzaj miejsce na dysku (df -h), działające usługi (systemctl --failed) i zapisy fail2ban.
• Tylko potrzebne usługi: nie instaluj tego, czego nie potrzebujesz. Każdy otwarty port to kolejna możliwa droga do środka.

Weryfikacja#

• apt update po aktualizacji wypisuje All packages are up to date.
• Nowe hasło root działa, a zakładka Pliki się loguje.
• Użytkownik jan loguje się przez SSH, a sudo whoami wypisuje root.
• sshd -T | grep -E "^(permitrootlogin|passwordauthentication|port) " pokazuje ustawione wartości.
• unattended-upgrade --dry-run --debug przebiega bez błędu.

Rozwiązywanie problemów#

Odcięto Cię od SSH#

Użyj konsoli w przeglądarce. Logujesz się hasłem root (nawet jeśli root jest zablokowany przez SSH) i naprawiasz błąd, na przykład usuwając plik /etc/ssh/sshd_config.d/00-zabezpeceni.conf i restartując SSH przez systemctl restart ssh.

sudo: jan is not in the sudoers file#

Użytkownik nie jest w grupie sudo. Jako root uruchom usermod -aG sudo jan; użytkownik musi się wylogować i zalogować ponownie, aby grupa zaczęła działać.

Zakładka Pliki zgłasza, że logowanie do VPS się nie powiodło#

Strefa klienta używa starych danych logowania. Otwórz Pliki › Zmień dane logowania i wpisz aktualnego użytkownika, port i hasło. Jeśli wyłączono logowanie hasłem albo SSH jest dozwolone tylko z Twojego adresu IP, zakładka nie zadziała (zobacz tabelę w sekcji Bezpieczeństwo a strefa klienta).

sshd -T pokazuje inną wartość niż ustawiono#

To samo ustawienie jest w innym pliku, który wczytuje się wcześniej (serwer SSH bierze pierwszą znalezioną wartość). Znajdź go:

grep -rni "permitrootlogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

• grep -rni – szuka tekstu we wszystkich plikach folderu (-r), bez rozróżniania wielkości liter (-i), i wypisuje numer linii (-n).

Zakomentuj linię w drugim pliku (postaw # na jej początku) albo zmień wartość bezpośrednio tam. Potem uruchom ponownie sshd -t && sshd -T | grep -i permitrootlogin i zrestartuj SSH.

Po zmianie portu SSH nadal nasłuchuje tylko na porcie 22#

Na Ubuntu 24.04 najprawdopodobniej pominięto systemctl daemon-reload. Uruchom je, a potem systemctl restart ssh.socket.

E: Could not get lock /var/lib/dpkg/lock-frontend#

W tle trwa inna instalacja, zwykle automatyczne aktualizacje (na nowym VPS po pierwszym starcie). Poczekaj kilka minut i uruchom polecenie ponownie. Nie zabijaj procesu.

Dalsza lektura#

• Ubuntu: serwer OpenSSH (otwiera się w nowym oknie)
• Ubuntu: automatyczne aktualizacje (otwiera się w nowym oknie)
• Debian Wiki: UnattendedUpgrades (otwiera się w nowym oknie)
• Strona podręcznika sshd_config (otwiera się w nowym oknie)