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
sudogotowego 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.
Wygeneruj parę kluczy 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 swój klucz publiczny na serwer
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ą
PasswordAuthenticationw 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
yesgdziekolwiek w wynikach, edytuj ten konkretny plik, nie głównysshd_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 SSH
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 noustawione 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.