Jak zabezpieczyć SSH na Ubuntu i Debian: Kompletny przewodnik serwera

Port 22 jest ciągle skanowany. Moment gdy uruchamiasz VPS z publicznym IP, zautomatyzowane boty zaczynają go bombardować w poszukiwaniu słabych haseł i domyślnych danych z obrazów chmurowych które nie były dotknięte. Utwardzanie SSH zajmuje około 15 minut i sprawia że twój serwer jest dramatycznie mniej interesujący dla każdego kto próbuje się włamać.

Wymaganie: Ten przewodnik wyłącza logowanie root. Musisz mieć niestandardowego użytkownika z uprawnieniami sudo gotowego przed uruchomieniem jakichkolwiek z tych kroków. Jeśli jeszcze tego nie zrobiłeś, postępuj zgodnie z naszym przewodnikiem Jak utworzyć użytkownika sudo na Ubuntu i Debian, potem wróć tutaj.

Skonfiguruj uwierzytelnianie oparte na kluczach SSH #

Jedna najskuteczniejsza zmiana jaką możesz zrobić. Logowania hasłowe mogą być siłowo złamane. Uwierzytelnianie oparte na kluczach nie może, nie w żadnym realistycznym przedziale czasowym.

Na swojej maszynie lokalnej, wygeneruj parę kluczy:

ssh-keygen -t ed25519 -C "your-server-label"

Użyj ed25519, jest szybszy i bezpieczniejszy od starszego algorytmu RSA. Gdy zostaniesz poproszony o hasło, ustaw je. Szyfruje klucz prywatny na dysku, więc nawet jeśli ktoś naruszy twój laptop, wciąż nie będzie mógł użyć klucza bez niego.

Skopiuj klucz publiczny na serwer. Zastąp youruser swoim rzeczywistym nazwą użytkownika sudo:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Przetestuj że klucz działa przed przejściem dalej. Otwórz nowe okno terminala i połącz się. Jeśli logujesz się bez monitu o hasło, klucz jest zainstalowany poprawnie. Nie zamykaj jeszcze swojej obecnej sesji, wciąż potrzebujesz jej jako zapasowej jeśli coś pójdzie nie tak w późniejszych krokach.

Opcjonalnie: dodaj wpis do ~/.ssh/config na swojej maszynie lokalnej dla szybkiego dostępu:

Host myserver
    HostName your-server-ip
    User youruser
    IdentityFile ~/.ssh/id_ed25519

Po tym, ssh myserver to wszystko co musisz wpisać.

Wyłącz logowanie root #

Loguj się przez SSH jako swój użytkownik sudo od tego momentu. Bezpośrednie logowanie root to ryzyko bezpieczeństwa, jeśli twoja sesja zostanie naruszona, atakujący ma pełny nieograniczony dostęp bez dodatkowych kroków.

Otwórz konfigurację demona SSH:

sudo nano /etc/ssh/sshd_config

Znajdź i zaktualizuj tę linię:

PermitRootLogin no

Jeśli kiedykolwiek potrzebujesz dostępu root na serwerze, zaloguj się jako swój użytkownik sudo i uruchom sudo su stamtąd.

Wyłącz uwierzytelnianie hasłem #

Twój klucz działa, więc teraz wyeliminuj logowania hasłowe całkowicie:

sudo nano /etc/ssh/sshd_config

Ustaw oba te:

PasswordAuthentication no
PubkeyAuthentication yes

Ważne: Niektóre wersje Ubuntu i Debian ustawiają PasswordAuthentication w pliku drop-in pod /etc/ssh/sshd_config.d/ który nadpisuje główną konfigurację. Sprawdź to:

grep -r "PasswordAuthentication" /etc/ssh/

Jeśli widzisz że jest ustawione na yes gdziekolwiek w wynikach, edytuj ten konkretny plik, nie główny sshd_config.

Zaostrz kilka dodatkowych ustawień #

Podczas gdy masz otwarty sshd_config, dodaj te aby dalej zredukować powierzchnię ataku:

# Rozłącz po 3 nieudanych próbach
MaxAuthTries 3

# Zamykaj nieuwierzytelnione połączenia szybciej
LoginGraceTime 30

# Wyłącz nieużywane funkcje
X11Forwarding no
AllowTcpForwarding no

Jeśli tylko konkretne nazwy użytkowników powinny móc logować się zdalnie, dodaj listę dozwolonych:

AllowUsers youruser

Żadne konto niewymienione na liście zostanie odrzucone na poziomie SSH, nawet z ważnym kluczem.

Zmień domyślny port #

Port 22 pojawia się na każdej liście celów domyślnych skanerów. Przeniesienie SSH na niestandardowy port nie powstrzyma zdeterminowanego atakującego od skanowania portów, ale eliminuje praktycznie cały zautomatyzowany szum. Logi autoryzacji spadają z setek nieudanych prób logowania dziennie do efektywnie zera.

W sshd_config, zaktualizuj port:

Port 2222

Wybierz dowolny nieużywany port powyżej 1024. Przed restartem SSH, zaktualizuj swoją zaporę aby zezwolić na nowy port i zamknąć stary:

sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw status

Upewnij się że 2222 pokazuje się jako ALLOW w wynikach przed przejściem dalej.

Zrestartuj SSH i zweryfikuj #

Zastosuj wszystkie swoje zmiany:

sudo systemctl restart ssh

Potem, w nowym oknie terminala (zachowaj swoją obecną sesję otwartą), przetestuj połączenie na nowym porcie:

ssh -p 2222 youruser@your-server-ip

Jeśli łączy się czysto, skończone. Jeśli nie, wróć do swojej obecnej sesji i debuguj. Uruchom sudo sshd -t aby sprawdzić sshd_config pod kątem błędów składni przed ponownym restartowaniem.

Typowe problemy:

• Zapora nie zaktualizowana dla nowego portu
• PasswordAuthentication no ustawione w pominiętym pliku który został przeoczony

Sprawdź co serwer faktycznie widzi #

Po zablokowaniu, sprawdź na żywo próby autoryzacji:

sudo journalctl -u ssh --since "1 hour ago" | grep "Failed"

Na poprawnie utwardzonym serwerze powinieneś nic nie widzieć, lub tylko garstkę prób na starym porcie cicho porzucanych przez zaporę.

Uwaga o fail2ban #

Z włączonym uwierzytelnianiem kluczowym SSH i wyłączonym uwierzytelnianiem hasłem, ataki siłowe na SSH są już niemożliwe. fail2ban staje się mniej krytyczny dla samego SSH. Mówiąc to, wciąż jest przydatny do ochrony innych usług jak Nginx i Apache, a uruchamianie go obok tych ustawień dodaje rozsądną warstwę obrony w głąb. Zobacz nasz przewodnik konfiguracji fail2ban fail2ban setup guide jeśli chcesz go dodać.

Jeśli chcesz bezpieczne miejsce do poćwiczenia tego procesu utwardzania bez ryzykowania serwera produkcyjnego, nasze plany Budget VPS są przystępną piaskownicą aby zablokować, zepsuć i zacząć od nowa tyle razy ile potrzebujesz.