Bezpieczna konfiguracja serwera SSH

Moduł 2: SSH i klucze · Czas czytania: 12 min

Cel lekcji: Po tej lekcji potrafią Państwo wyłączyć logowanie hasłem oraz logowanie roota hasłem, sprawdzić, które ustawienie naprawdę obowiązuje, i zrobić to bez zablokowania sobie dostępu.

Kluczowe pojęcia: sshd, sshd_config, sshd_config.d, liczy się pierwsza wartość, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, druga sesja, cloud-init, ssh.socket

Najpierw siatka bezpieczeństwa

W tej lekcji zamykamy drzwi, przez które sami Państwo muszą przechodzić. Jedna literówka może sprawić, że nie będą Państwo mogli się już zalogować. Dlatego zawsze, zanim Państwo zaczną:

1. Dwa klucze działają (lekcja 2.1), a w nowym oknie sprawdzili Państwo, że logowanie kluczem się udaje.
2. Snapshot Państwa VPS. W WebOké tworzą go Państwo w panelu VPS, u innych dostawców nazywa się to również snapshot lub image. Jeśli coś pójdzie nie tak, przywracają go Państwo.
3. Konsolę swojego dostawcy znają Państwo: można się przez nią dostać do serwera bez SSH.
4. Bieżąca sesja SSH pozostaje otwarta do samego końca. Trwająca sesja działa dalej, gdy zmieniają Państwo ustawienia lub przeładowują usługę. Każdą zmianę testują Państwo w drugim oknie.

Gdzie znajdują się ustawienia

Serwer SSH nazywa się sshd. Jego ustawienia znajdują się w /etc/ssh/sshd_config. W Debianie i Ubuntu na samej górze tego pliku jest taki wiersz:

Include /etc/ssh/sshd_config.d/*.conf

Wszystkie pliki z .conf w katalogu sshd_config.d są więc wczytywane przed resztą pliku głównego, w kolejności alfabetycznej. To wygodne: własne ustawienia umieszczają Państwo we własnym pliku, a pliku głównego nie ruszają, dzięki czemu aktualizacja pakietu nie naruszy Państwa zmian.

Ma to jednak skutek, który zaskakuje wiele osób. W sshd_config obowiązuje zasada: dla każdego ustawienia liczy się pierwsza wartość, na którą trafi sshd. Późniejsze wiersze z tym samym ustawieniem są ignorowane. Kto na końcu sshd_config wpisze PasswordAuthentication no, nie wygra więc z plikiem w sshd_config.d, który mówi yes.

Pułapka cloud-init

Wiele obrazów VPS jest konfigurowanych przy pierwszym uruchomieniu przez cloud-init. W zależności od ustawień obrazu i instalacji cloud-init zapisuje plik taki jak /etc/ssh/sshd_config.d/50-cloud-init.conf, zawierający na przykład:

PasswordAuthentication yes

Ponieważ ten plik jest wczytywany przed plikiem głównym, logowanie hasłem pozostaje włączone, cokolwiek wpiszą Państwo w sshd_config. Prosimy więc niczego nie zakładać, tylko sprawdzić:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Są dwa porządne rozwiązania: zmienić w tym pliku wartość na no albo umieścić własne ustawienia w pliku, który jest wcześniej w alfabecie, na przykład 00-beveiliging.conf. Plik 99-mijn.conf właśnie nie zadziała, bo wtedy cloud-init już wygrał.

Ustawienia, które mają znaczenie

Prosimy utworzyć własny plik:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

o następującej treści:

# Logowanie wyłącznie kluczem
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Co oznacza każdy wiersz?

• PasswordAuthentication no: serwer nie przyjmuje już haseł. Domyślna wartość w OpenSSH to yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" to drugi sposób pytania o hasło, przez PAM. Jeśli pozostawią go Państwo włączonego, ktoś nadal może próbować hasła, nawet gdy PasswordAuthentication ma wartość no. W starszych poradnikach to ustawienie nazywa się ChallengeResponseAuthentication; od OpenSSH 8.7 jest to przestarzała, inna nazwa tego samego. Debian domyślnie ustawia je już na no, ale prosimy mimo to je wpisać: wtedy wszystko jest jasne i zgadza się także na innych systemach.
• PermitRootLogin prohibit-password: root może się logować, ale tylko kluczem. Od OpenSSH 7.0 jest to wartość domyślna. Bardziej restrykcyjne jest PermitRootLogin no: root w ogóle nie może wejść przez SSH, logują się Państwo jako zwykły użytkownik i używają sudo (lekcja 3.2). Wartość no prosimy ustawić dopiero wtedy, gdy mają Państwo pewność, że logowanie jako ten użytkownik i sudo działają.

Opcjonalnie, dla chętnych:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers wpuszcza tylko wymienionych użytkowników; każda inna nazwa jest odrzucana, nawet jeśli ma ważny klucz. To przydatne, ale prosimy nie zapomnieć o sobie i o uzupełnieniu listy, gdy dodają Państwo drugiego administratora. AuthenticationMethods publickey mówi w jednym wierszu, że obowiązują wyłącznie klucze.

Testowanie, zastosowanie, kontrola

Najpierw każą Państwo sshd sprawdzić plik. To niczego nie uruchamia i niczego nie zmienia:

root@web1:~# sshd -t
root@web1:~#

Brak wyniku oznacza: brak błędów. Przy literówce zobaczą Państwo wiersz i plik. Dopiero wtedy przeładowują Państwo usługę:

root@web1:~# systemctl reload ssh

W Debianie i Ubuntu usługa nazywa się ssh, w AlmaLinux i Rocky Linux sshd.

Następnie sprawdzają Państwo, która wartość obowiązuje naprawdę. sshd -T pokazuje pełną, wyliczoną konfigurację z uwzględnieniem wszystkich plików Include:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password to stara nazwa prohibit-password. Wersje OpenSSH sprzed 10.1, takie jak w Debianie 13 i Ubuntu 24.04, pokazują jeszcze starą nazwę; nowsze pokazują prohibit-password. Znaczenie jest takie samo.)

A teraz najważniejsze: prosimy przetestować w drugim oknie, gdy pierwsze pozostaje otwarte.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Jeśli to działa, prosimy celowo spróbować zalogować się hasłem. Ta próba musi się nie udać:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

Za Permission denied w nawiasie widać, jakie metody logowania serwer jeszcze oferuje. Jeśli jest tam tylko publickey, wszystko jest w porządku. Jeśli widnieje tam też password lub keyboard-interactive, to gdzieś nadal obowiązuje inna wartość: prosimy sprawdzić ponownie za pomocą sshd -T.

Dokładnie tę listę sprawdza też zadanie z kursu, z zewnątrz. Klient SSH przy każdym połączeniu najpierw pyta, które metody są dozwolone, za pomocą żądania typu "none". Serwer odpowiada listą, bez próbowania jakiegokolwiek hasła czy klucza.

Ubuntu 24.04 i nowsze: ssh.socket

W Ubuntu od wersji 22.10 na porcie 22 nie nasłuchuje sam sshd, lecz systemd, przez ssh.socket. Dopiero gdy przychodzi połączenie, systemd uruchamia usługę SSH. Dla ustawień z tej lekcji nie ma to znaczenia: wystarczy systemctl reload ssh lub restart ssh.

Ma to jednak znaczenie, gdy zmieniają Państwo port lub adres nasłuchiwania (Port, ListenAddress). Od Ubuntu 24.04 systemd odczytuje te wartości z sshd_config, ale dopiero po:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Jeśli Państwo o tym zapomną, serwer nadal będzie nasłuchiwał na starym porcie. Co gorsza: jeśli najpierw ustawią Państwo zaporę na nowy port, a SSH zostanie na starym, zablokują sobie Państwo dostęp. Zawsze prosimy sprawdzić za pomocą ss -tlnp | grep ssh, gdzie naprawdę trwa nasłuchiwanie (lekcja 5.1), i otworzyć nowy port w zaporze, zanim zamkną Państwo stary. Czy inny port ma sens, dowiedzą się Państwo z lekcji 2.3.

Gdy jednak coś pójdzie nie tak

Jeśli nie mogą się Państwo zalogować, prosimy otworzyć konsolę dostawcy, zalogować się jako root (hasłem, bo konsola to "klawiatura podłączona do serwera", a nie SSH) i wycofać swój plik:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Jeśli i to się nie uda, prosimy przywrócić snapshot. W WebOké w panelu VPS można też ustawić nowe hasło roota; inni dostawcy często mają podobny przycisk lub tryb ratunkowy (rescue).

W AlmaLinux i Rocky Linux

Usługa nazywa się sshd (systemctl reload sshd). Również tam na górze jest Include /etc/ssh/sshd_config.d/*.conf, a system dostarcza własne pliki w tym katalogu; obowiązuje ta sama zasada "liczy się pierwsza wartość". Jeśli zmieniają Państwo port, SELinux musi również na niego zezwolić (semanage port -a -t ssh_port_t -p tcp 2222), a firewalld musi go otworzyć.

Podsumowanie

• W sshd_config liczy się pierwsza wartość; pliki w sshd_config.d są wczytywane jako pierwsze. Własne ustawienia prosimy umieścić w pliku takim jak 00-beveiliging.conf.
• Prosimy ustawić PasswordAuthentication no oraz KbdInteractiveAuthentication no; root tylko z kluczem (prohibit-password) albo wcale (no).
• Przed przeładowaniem prosimy sprawdzić konfigurację za pomocą sshd -t, a za pomocą sshd -T, która wartość naprawdę obowiązuje; uwaga na 50-cloud-init.conf.
• Prosimy testować w drugim oknie i trzymać pierwszą sesję otwartą. Warto znać konsolę i wcześniej wykonać snapshot.
• W Ubuntu 24.04+ zmiana portu wymaga systemctl daemon-reload i systemctl restart ssh.socket.

Quiz

Zadanie

Zadanie Z2.2: Logowanie hasłem jest wyłączone. Prosimy wyłączyć logowanie hasłem i keyboard-interactive tak jak w tej lekcji, a następnie pozwolić programowi sprawdzić serwer z zewnątrz. Prosimy podać adres IP lub nazwę hosta serwera, port SSH (domyślnie 22) oraz nazwę użytkownika, którą sami się Państwo logują (na przykład anna, a nie root ani wymyśloną nazwę). Program się nie loguje: pyta jedynie, tak jak każdy klient SSH przed zalogowaniem, jakie metody logowania serwer oferuje temu użytkownikowi. Prawidłowy wynik: tylko publickey.

Przeczytaj więcej

Kroki opisane w tych artykułach dotyczą panelu VPS w WebOké; u innych dostawców wygląda to podobnie.

• Zabezpieczanie VPS: pierwsze pięć minut
• Brak dostępu do VPS: co teraz?
• Snapshoty i kopie zapasowe VPS
• Dokumentacja sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189