Klucze SSH zamiast hasła: logowanie na VPS krok po kroku

Świeżo uruchomiony serwer z publicznym adresem IP zaczyna dostawać próby logowania w ciągu kilkunastu minut. Nie dlatego, że ktoś celuje akurat w Ciebie, tylko dlatego, że automaty skanują całe zakresy adresów i próbują najpopularniejszych haseł na koncie root. Klucz SSH kończy tę konkurencję raz na zawsze, bo nie ma już czego zgadywać. Poniżej cała procedura, razem z zabezpieczeniem przed najczęstszym błędem, czyli odcięciem się od własnej maszyny.

Dwa pliki, jedna zasada

Para kluczy to dwa powiązane matematycznie pliki. Klucz prywatny zostaje na Twoim komputerze i nie opuszcza go nigdy. Klucz publiczny wgrywasz na serwer i możesz go rozdawać bez obaw, bo służy wyłącznie do sprawdzenia, czy druga strona posiada odpowiadający mu klucz prywatny.

Podczas logowania serwer stawia zadanie, które da się rozwiązać tylko kluczem prywatnym. Hasło nigdy nie jest przesyłane, więc nie ma czego przechwycić ani zgadnąć. Serwery RapidDC obsługują uwierzytelnianie kluczem, a sam klucz możesz wskazać już przy zakładaniu maszyny.

Generowanie pary kluczy

Na Linuksie, macOS i w Windows 10 lub nowszym wystarczy wbudowany klient:

ssh-keygen -t ed25519 -C "laptop-robocze"

Kilka uwag do tego polecenia. Typ ed25519 jest dziś domyślnym wyborem: krótszy i szybszy od RSA przy porównywalnym bezpieczeństwie. Jeśli musisz obsłużyć bardzo stary serwer, użyj -t rsa -b 4096. Komentarz po -C to tylko etykieta, ale bardzo pomaga, gdy po roku patrzysz na listę kluczy i próbujesz sobie przypomnieć, który komputer jest który.

Program zapyta o hasło do klucza. Ustaw je. To hasło chroni plik na dysku, więc jeśli laptop zginie, sam klucz nadal jest bezużyteczny dla znalazcy. Żeby nie wpisywać go przy każdym połączeniu, dodaj klucz do agenta poleceniem ssh-add.

Powstaną dwa pliki: ~/.ssh/id_ed25519 (prywatny, nie wysyłaj go nigdzie) oraz ~/.ssh/id_ed25519.pub (publiczny).

Wgranie klucza na serwer

Najprościej jednym poleceniem:

ssh-copy-id uzytkownik@adres-ip-serwera

Polecenie zaloguje się hasłem ostatni raz i dopisze klucz publiczny do pliku ~/.ssh/authorized_keys na serwerze. Jeśli ssh-copy-id nie jest dostępne, ten sam efekt uzyskasz ręcznie: utwórz na serwerze katalog ~/.ssh z uprawnieniami 700, plik authorized_keys z uprawnieniami 600 i wklej do niego zawartość klucza publicznego. Uprawnienia są tu istotne, bo serwer SSH z zasady ignoruje pliki dostępne dla innych użytkowników.

Teraz najważniejszy krok, który łatwo pominąć: otwórz drugie okno terminala i zaloguj się kluczem, zanim cokolwiek zmienisz w konfiguracji. Pierwsze połączenie zostaw otwarte. To jest Twoja droga powrotna, jeśli coś pójdzie nie tak.

Trzy ustawienia, które warto zmienić

Konfiguracja serwera znajduje się w /etc/ssh/sshd_config. Po sprawdzeniu, że logowanie kluczem działa, zmień trzy rzeczy:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Pierwsza linia wyłącza hasła i to ona odcina automaty. Druga pozwala na logowanie na konto root wyłącznie kluczem, co jest rozsądnym kompromisem między wygodą a bezpieczeństwem. Jeśli pracujesz na koncie zwykłego użytkownika z sudo, możesz ustawić tam no.

Po zapisaniu przeładuj usługę poleceniem systemctl reload sshd, a następnie w nowym oknie sprawdź, czy nadal się logujesz. Dopiero gdy to zadziała, zamknij pierwsze połączenie. Gdy coś pójdzie źle, zostaje konsola z panelu maszyny, ale znacznie wygodniej jest po prostu nie zamykać otwartej sesji.

Zmiana portu i co ona naprawdę daje

Przeniesienie SSH z portu 22 na inny ogranicza hałas w logach, bo większość automatów skanuje wyłącznie porty standardowe. Nie jest to jednak zabezpieczenie, tylko sprzątanie: skanowanie całego zakresu portów zajmuje chwilę i wystarczy, by usługę odnaleźć.

Realne zabezpieczenie daje połączenie trzech rzeczy: logowania wyłącznie kluczem, zapory przepuszczającej ruch na port SSH tylko z zaufanych adresów oraz narzędzia blokującego powtarzające się nieudane próby. O samej zaporze pisaliśmy we wpisie o tym, czym jest zapora sieciowa.

Praca z kilku komputerów

Klucz jest przypisany do maszyny, nie do człowieka, więc nie kopiuj klucza prywatnego między urządzeniami. Wygeneruj osobną parę na każdym komputerze i dopisz kolejne klucze publiczne do authorized_keys na serwerze. Plik przyjmuje dowolną liczbę wpisów, po jednym w linii.

Ta sama zasada obowiązuje w zespole. Każda osoba ma własny klucz, a odebranie dostępu sprowadza się do usunięcia jednej linii z pliku. Przy współdzielonym haśle odebranie dostępu jednej osobie oznacza zmianę hasła wszystkim.

Podsumowanie

Konfiguracja zajmuje kwadrans i zostaje z Tobą na lata. Wygeneruj parę, wgraj klucz publiczny, sprawdź logowanie w drugim oknie, wyłącz hasła i dopiero wtedy zamknij pierwszą sesję.

Jeśli dopiero planujesz własną maszynę, serwery VPS RapidDC działają na pełnej wirtualizacji KVM, dają dostęp root, dedykowany adres IP i obsługują klucze SSH, a reinstalacje są nielimitowane, więc eksperymentowanie nic nie kosztuje. Zanim zaczniesz, przejrzyj wpis o łączeniu się z serwerem VPS przez SSH.

FAQ – najczęściej zadawane pytania o klucze SSH

Co się stanie, gdy zgubię klucz prywatny?

Stracisz dostęp do serwera tą drogą. Dlatego warto mieć drugi klucz z innego urządzenia dopisany do authorized_keys albo dostęp do konsoli z panelu maszyny. Klucza prywatnego nie da się odtworzyć z publicznego.

Czy hasło do klucza jest konieczne?

Formalnie nie, ale bez niego plik klucza wystarcza do zalogowania się każdemu, kto go zdobędzie. Z hasłem i agentem SSH wpisujesz je raz na sesję, więc koszt wygody jest minimalny wobec zysku.

Czym różni się ed25519 od RSA?

Ed25519 daje krótszy klucz, szybsze uwierzytelnianie i bezpieczeństwo porównywalne z RSA 4096. RSA wybieraj tylko wtedy, gdy serwer docelowy jest na tyle stary, że nie obsługuje nowszego algorytmu.

Czy mogę używać jednego klucza na kilku serwerach?

Tak i jest to typowa praktyka. Ten sam klucz publiczny dopisujesz na każdym serwerze, do którego chcesz mieć dostęp. Osobne klucze generuj per urządzenie, a nie per serwer.

Jak sprawdzić, że logowanie hasłem naprawdę zostało wyłączone?

Spróbuj połączyć się z pominięciem kluczy poleceniem ssh -o PubkeyAuthentication=no uzytkownik@adres. Poprawnie skonfigurowany serwer odrzuci takie połączenie bez pytania o hasło.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu RapidDC. Grafika ilustracyjna została wygenerowana przez AI.