SSH hardening krok po kroku – bezpieczna konfiguracja serwera Linux

Przez /

SSH jest jednym z najważniejszych punktów wejścia do serwera Linux. Jeżeli serwer jest dostępny z Internetu, próby logowania pojawiają się zwykle bardzo szybko. Samo przeniesienie usługi na inny port nie rozwiązuje problemu — najważniejsze są klucze, ograniczenie sposobów logowania, rozsądne reguły dostępu i bezpieczne wdrażanie zmian.

Poniższy zestaw ustawień traktuję jako praktyczny punkt startowy. Nie każda wartość pasuje do każdego środowiska, dlatego najważniejsza zasada brzmi: zmieniaj konfigurację etapami i zawsze zostaw sobie drugą aktywną sesję SSH do testów.

Najgroźniejszy błąd podczas hardeningu SSH to nie słaba wartość parametru, tylko odcięcie sobie jedynej drogi dostępu do serwera.

1. Najpierw sprawdź obecną konfigurację

sudo sshd -t
sudo sshd -T | less
systemctl status sshd || systemctl status ssh

sshd -t sprawdza składnię konfiguracji. sshd -T pokazuje konfigurację wynikową po uwzględnieniu domyślnych wartości i plików dołączanych przez Include. To lepszy punkt odniesienia niż samo czytanie /etc/ssh/sshd_config.

2. Klucze zamiast haseł

Najpierw skonfiguruj logowanie kluczem publicznym i sprawdź je w nowej sesji. Dopiero wtedy wyłączaj hasła.

ssh-keygen -t ed25519 -a 100
ssh-copy-id admin@server.example.com
ssh admin@server.example.com

Na serwerze klucz użytkownika trafia zwykle do ~/.ssh/authorized_keys. Katalog i plik powinny mieć odpowiednie uprawnienia:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

3. Wyłączenie logowania root

Do codziennej administracji lepiej używać osobnego konta oraz sudo. W konfiguracji SSH:

PermitRootLogin no

Przed zastosowaniem tej zmiany upewnij się, że istnieje inne konto administracyjne i że faktycznie może używać sudo.

4. Wyłączenie haseł — dopiero po teście klucza

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Po zmianie nie zamykaj obecnej sesji. Otwórz drugie okno terminala i sprawdź logowanie kluczem. Jeżeli nowa sesja działa, dopiero wtedy uznaj zmianę za bezpiecznie wdrożoną.

W środowiskach z PAM, MFA lub centralnym uwierzytelnianiem ustawienia mogą wyglądać inaczej. Nie wyłączaj mechanizmu interaktywnego w ciemno, jeżeli jest częścią logowania wieloskładnikowego.

5. Ograniczenie użytkowników

AllowUsers admin backup
# albo
AllowGroups ssh-users

Jeżeli tylko kilka kont powinno łączyć się przez SSH, jawne ograniczenie listy użytkowników lub grup zmniejsza powierzchnię ataku i porządkuje administrację.

6. Mniej prób i krótszy czas logowania

MaxAuthTries 3
LoginGraceTime 30

Te wartości nie zastępują ochrony sieciowej ani mechanizmów blokowania agresywnych prób, ale ograniczają czas i liczbę prób w pojedynczej sesji.

7. Forwarding tylko wtedy, gdy jest potrzebny

SSH potrafi tunelować TCP, przekazywać agenta i obsługiwać X11. Są to przydatne funkcje, ale jeżeli na danym serwerze nie są potrzebne, można je ograniczyć.

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

Nie ustawiaj tego automatycznie wszędzie. Bastion, tunel administracyjny czy automatyzacja mogą celowo korzystać z forwardingów.

8. Przykładowy ostrożny fragment konfiguracji

# /etc/ssh/sshd_config.d/10-hardening.conf

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers admin
X11Forwarding no

Na wielu współczesnych dystrybucjach wygodniej jest utworzyć osobny plik w sshd_config.d/ niż modyfikować cały główny plik konfiguracji.

9. Test przed reloadem

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|allowusers'

Jeżeli test przechodzi poprawnie, przeładuj lub zrestartuj usługę zgodnie z dystrybucją:

sudo systemctl reload sshd
# albo
sudo systemctl reload ssh

Po zmianie ponownie testuj w nowej sesji. Obecną zostaw otwartą do czasu potwierdzenia dostępu.

10. Logi SSH podczas diagnostyki

journalctl -u sshd -b -n 100
journalctl -u ssh -b -n 100
journalctl --since "15 minutes ago" | grep -i ssh

Jeżeli klient odrzuca klucz, log serwera zwykle od razu pokazuje powód: zły właściciel pliku, nieprawidłowe prawa do katalogu, niedozwolony użytkownik albo problem z metodą uwierzytelniania.

Warto połączyć ten temat z artykułami Bezpieczeństwo w systemach Linux, Zarządzanie użytkownikami i grupami oraz Systemy logowania i audytu.

11. A co z fail2ban i firewallem?

Są przydatne jako kolejna warstwa, ale nie naprawiają słabej konfiguracji SSH. Najpierw klucze, brak logowania root i ograniczenie metod uwierzytelniania. Dopiero później warto dodać ograniczenia sieciowe, rate limiting, fail2ban albo dostęp tylko przez VPN/bastion.

Podsumowanie

Najbezpieczniejszy hardening SSH to nie lista agresywnych ustawień, tylko kontrolowany proces: skonfiguruj klucz, sprawdź drugą sesję, ogranicz użytkowników, wyłącz niepotrzebne metody i testuj konfigurację przez sshd -t przed każdym przeładowaniem. Dzięki temu wzmacniasz serwer bez ryzyka przypadkowego odcięcia dostępu.

Przewijanie do góry