Jak zarządzać kluczami SSH w systemie Linux

Jak działają klucze SSH

Klucz SSH to para plików: klucz prywatny, który pozostaje na urządzeniu, oraz klucz publiczny, który kopiuje się na każdy serwer, do którego wymagany jest dostęp. Podczas nawiązywania połączenia serwer wykorzystuje klucz publiczny do wysłania wyzwania, na które odpowiedzieć może tylko pasujący klucz prywatny. Klucz prywatny nigdy nie opuszcza urządzenia, dzięki czemu żadne dane uwierzytelniające nie są przesyłane przez sieć, a przejęcie serwera nie pozwala na kradzież sekretu. Z tego powodu klucze są bezpieczniejsze niż hasła. Prawidłowe zarządzanie kluczami SSH opiera się na czterech nawykach: jeden klucz na urządzenie, odpowiednie uprawnienia plików wymagane przez sshd, plik ~/.ssh/config eliminujący konieczność wpisywania opcji oraz wiedza, jak usunąć klucz w przypadku utraty laptopa.

Niniejszy przewodnik omawia każdy z tych nawyków w systemie Ubuntu 24.04, choć większość informacji ma zastosowanie do dowolnego serwera Linux oraz każdej nowszej wersji OpenSSH.

Przed rozpoczęciem warto wyjaśnić kwestię terminologii, aby uniknąć poważnych błędów. Klucz publiczny nie jest poufny. Można go wkleić do zgłoszenia, wysłać e-mailem lub opublikować, a nikt nie będzie w stanie zalogować się za jego pomocą. Kluczem poufnym jest klucz prywatny. Każdy, kto skopiuje ten plik i zna jego hasło (jeśli zostało ustawione), uzyskuje pełne uprawnienia użytkownika w odniesieniu do serwerów.

Utworzenie klucza: ed25519 to właściwy wybór domyślny

Na własnym komputerze, nie na serwerze, wykonaj polecenie:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 określa typ klucza. Ed25519 to nowoczesny standard: klucze są krótkie, szybkie i obsługiwane przez każde wydanie OpenSSH od 2014 roku. Użyj ssh-keygen -t rsa -b 4096 tylko wtedy, gdy musisz połączyć się ze starym urządzeniem, które nie obsługuje ed25519. -C "laptop" ustawia komentarz. Komentarz nie pełni funkcji kryptograficznej, ale pozwala zidentyfikować klucz w pliku authorized_keys na serwerze po dwóch latach, dlatego warto wpisać nazwę urządzenia, na którym znajduje się klucz.

ssh-keygen pyta o lokalizację zapisu klucza. Zaakceptuj wartość domyślną, ~/.ssh/id_ed25519. Następnie pojawi się prośba o hasło (passphrase). Ustaw je; sekcja dotycząca hasła poniżej wyjaśnia, dlaczego nie wpływa ono na codzienną wygodę użytkowania. W rezultacie otrzymasz dwa pliki: ~/.ssh/id_ed25519 to klucz prywatny, a ~/.ssh/id_ed25519.pub to klucz publiczny. Wyświetl zawartość klucza publicznego:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Jest to jedna linia: typ klucza, dane klucza oraz komentarz. Ta linia jest tym, co należy umieścić na serwerach.

Jeden klucz na urządzenie, nie na serwer

Pytanie, które zadaje każdy na początku: czy potrzebuję nowego klucza dla każdego serwera? Nie. Należy utworzyć jeden klucz dla każdego urządzenia, z którego korzystasz, a następnie umieścić ten klucz publiczny na każdym serwerze, do którego urządzenie musi mieć dostęp. Klucz identyfikuje urządzenie. Plik authorized_keys na każdym serwerze stanowi listę urządzeń, które mają przyznany dostęp.

Jest to model, który skaluje się poprawnie, podczas gdy alternatywne rozwiązania zawodzą w przewidywalny sposób. Klucz na każdy serwer oznacza, że laptop obsługujący dwadzieścia serwerów przechowuje dwadzieścia kluczy prywatnych, co prowadzi do utraty kontroli nad tym, który klucz jest który. Jeden klucz współdzielony przez wszystkie urządzenia jest jeszcze gorszy: w przypadku kradzieży laptopa nie można unieważnić dostępu dla tego urządzenia bez zablokowania dostępu dla komputera stacjonarnego, ponieważ oba posiadają ten sam klucz prywatny. Wymusza to wymianę klucza wszędzie i ponowną dystrybucję na wszystkie urządzenia jednocześnie.

Przy modelu jednego klucza na urządzenie, utrata laptopa kosztuje usunięcie tylko jednej linii na każdym serwerze: należy usunąć linię odpowiadającą laptopowi z pliku authorized_keys, a wszystkie pozostałe urządzenia zachowują dostęp. Komentarz ustawiony za pomocą -C ułatwia szybkie odnalezienie tej linii.

Zasada stojąca za tym modelem: klucz prywatny jest tworzony na urządzeniu i ginie wraz z nim. Nigdy nie kopiuj klucza prywatnego na drugą maszynę i nigdy nie przesyłaj go na serwer. Gdy nowe urządzenie wymaga dostępu, wygeneruj na nim nowy klucz.

Umieszczenie klucza publicznego na serwerze

Najprostszym sposobem jest użycie ssh-copy-id, narzędzia dostarczanego wraz z OpenSSH:

ssh-copy-id matt@10.0.0.10

Narzędzie to loguje się przy użyciu dostępnej metody, zazwyczaj hasła, dopisuje klucz publiczny do pliku ~/.ssh/authorized_keys na serwerze oraz tworzy katalog i plik z odpowiednimi uprawnieniami, jeśli te nie istnieją. Należy przetestować działanie, otwierając nową sesję SSH: serwer powinien zezwolić na dostęp bez pytania o hasło do konta. Jeśli klucz posiada hasło (passphrase), własna stacja robocza może poprosić o jego podanie; jest to monit lokalny, a nie hasło serwera.

Jeśli logowanie hasłem zostało już wyłączone, ssh-copy-id nie uzyska dostępu, dlatego należy dodać linię ręcznie. Należy zalogować się przez działającą sesję lub konsolę WWW dostawcy i wykonać na serwerze następujące polecenie:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Wewnątrz cudzysłowu należy wkleić rzeczywisty klucz publiczny, czyli pełną linię z pliku id_ed25519.pub. Plik authorized_keys zawiera jeden klucz publiczny w każdej linii i stanowi kompletną bazę dostępu: dodanie urządzenia polega na dopisaniu linii, a cofnięcie uprawnień na jej usunięciu. Na nowym serwerze krok ten należy wykonać w ramach pierwszych 10 minut na nowym VPS, bezpośrednio przed wyłączeniem logowania hasłem.

Uprawnienia uniemożliwiające logowanie kluczem

Jest to najczęstsza przyczyna niepowodzenia logowania kluczem, która po stronie klienta przebiega bez żadnego komunikatu. Usługa sshd działa domyślnie z StrictModes yes w systemie Ubuntu 24.04, co oznacza, że odmawia użycia pliku authorized_keys, jeśli inni użytkownicy mogą go edytować. Jeśli plik, katalog ~/.ssh lub katalog domowy mogą być zapisywane przez kogokolwiek innego niż właściciel, sshd ignoruje klucz i przechodzi do żądania hasła, nie wyświetlając wyjaśnienia po stronie klienta. (OpenSSH w Ubuntu dopuszcza tylko jeden wąski wyjątek: plik z uprawnieniami zapisu dla grupy, do której należy tylko użytkownik. Nie należy na tym polegać; należy zachować poniższe tryby). Przyczyna jest widoczna wyłącznie w dzienniku serwera:

sudo grep 'Authentication refused' /var/log/auth.log

W obrazach minimalnych bez rsyslog plik auth.log nie istnieje; ten sam wpis znajduje się w dzienniku: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

Rozwiązaniem są dwie zmiany uprawnień oraz weryfikacja właściciela, wykonane na serwerze przez danego użytkownika:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

Zasada, o której należy pamiętać: 700 dla katalogu .ssh, 600 dla całej jego zawartości. Te same wartości obowiązują na komputerze lokalnym, ponieważ klient również przeprowadza weryfikację. Klucz prywatny możliwy do odczytania przez innych użytkowników powoduje, że ssh odrzuca klucz, a tym razem błąd jest wyraźnie komunikowany:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 rozwiązuje ten problem.

~/.ssh/config: koniec z wpisywaniem opcji

Plik ~/.ssh/config na komputerze lokalnym pozwala przypisać każdemu serwerowi krótką nazwę i zapamiętać opcje, które trzeba by wpisywać ręcznie. Należy utworzyć go z uprawnieniami 600 i dodać blok Host dla każdego serwera:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Teraz ssh web1 zastępuje ssh -p 22 matt@10.0.0.10, a ta sama krótka nazwa działa w scp, rsync oraz git, ponieważ wszystkie te narzędzia odczytują ten plik. HostName to rzeczywisty adres, User eliminuje konieczność wpisywania nazwy użytkownika, a IdentityFile wskazuje, który klucz ma zostać użyty.

IdentitiesOnly yes wymaga osobnego omówienia, ponieważ rozwiązuje problem niejasnych błędów. Gdy agent przechowuje wiele kluczy, klient oferuje je serwerowi jeden po drugim, a serwer traktuje każdą taką próbę jako nieudaną. Przy wystarczającej liczbie załadowanych kluczy następuje Received disconnect: Too many authentication failures, zanim klient zdąży użyć właściwego klucza. IdentitiesOnly yes sprawia, że klient oferuje wyłącznie klucz wskazany w IdentityFile, dzięki czemu błąd ten nie występuje.

Hasła i ssh-agent

Hasło szyfruje plik klucza prywatnego na dysku. Bez niego każda osoba, która skopiuje plik, może go natychmiast użyć; z hasłem skradziony plik jest bezużyteczny do momentu odgadnięcia hasła. W przypadku klucza na laptopie jest to dokładnie taka ochrona, jakiej potrzeba, ponieważ laptopy są kradzione, a ich kopie zapasowe wyciekają.

Powodem, dla którego hasło w praktyce nie stanowi obciążenia, jest ssh-agent. Agent przechowuje odszyfrowany klucz w pamięci, więc hasło wpisuje się tylko raz na sesję logowania, a każde kolejne połączenie jest natychmiastowe. Większość dystrybucji Linux na komputery stacjonarne oraz macOS uruchamia agenta automatycznie. Klucz można załadować do agenta za pomocą:

ssh-add ~/.ssh/id_ed25519

ssh-add -l wyświetla listę kluczy przechowywanych obecnie przez agenta. Jedna uwaga: przekazywanie agenta (ssh -A) pozwala zdalnemu serwerowi używać agenta do dalszego uwierzytelniania podczas trwania połączenia, dlatego należy włączać tę opcję tylko wobec serwerów w pełni zaufanych, a domyślnie pozostawiać ją wyłączoną.

Rotacja i unieważnianie: procedura na wypadek utraty laptopa

Unieważnienie zwykłego klucza SSH polega wyłącznie na usunięciu jego linii z pliku authorized_keys na każdym serwerze, na którym się znajduje. Nie istnieje żaden urząd certyfikacji, który wymagałby powiadomienia, ani data ważności, na którą trzeba czekać. W momencie usunięcia linii, nowe próby logowania przy użyciu tego klucza kończą się niepowodzeniem.

Przeprowadź tę procedurę teraz, póki nie jest to sytuacja awaryjna. Wybierz serwer, otwórz ~/.ssh/authorized_keys i znajdź klucz po jego komentarzu. Usuń linię za pomocą edytora lub odfiltruj ją na podstawie komentarza:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Następnie potwierdź z urządzenia, dla którego właśnie unieważniono dostęp, że logowanie kończy się błędem, a z innego urządzenia, że logowanie nadal działa. Zwróć uwagę na jeden szczegół: usunięcie klucza nie zamyka już otwartych sesji, ponieważ klucz jest weryfikowany tylko podczas logowania. Jeśli unieważniasz dostęp dla skradzionego urządzenia, sprawdź również who na serwerze i zakończ wszystkie sesje, których nie rozpoznajesz.

Rotacja to ta sama operacja wykonana w innej kolejności: wygeneruj nowy klucz na urządzeniu, zainstaluj go za pomocą ssh-copy-id, potwierdź, że logowanie nowym kluczem działa, a następnie usuń starą linię. Wykonuj to, gdy urządzenie zmienia właściciela, gdy klucz mógł zostać ujawniony lub gdy ktoś odchodzi z zespołu. Ręczne wykonanie tego na dwóch serwerach jest dopuszczalne; przy dwudziestu jest to zadanie dla automatyzacji, a zarządzanie wieloma serwerami Linux pokazuje, jak wypchnąć ten sam stan authorized_keys do całej floty.

Czego nie robić

• Nie należy używać jednego klucza prywatnego na wszystkich urządzeniach. Uniemożliwia to unieważnienie dostępu dla jednego skradzionego urządzenia bez konieczności wymiany klucza w każdym miejscu.

• Nie należy umieszczać klucza prywatnego w repozytorium git, nawet prywatnym. Zautomatyzowane skanery monitorują publiczne repozytoria i próbują wykorzystać wyciekłe klucze w ciągu kilku minut od wypchnięcia zmian, a repozytorium udostępnione publicznie w przyszłości ujawnia całą swoją historię.

• Nie należy przesyłać klucza prywatnego z laptopa na serwer w celu uzyskania dostępu do kolejnego serwera. Należy wygenerować osobny klucz bezpośrednio na serwerze i autoryzować go tylko tam, gdzie jest to wymagane.

• Nie należy wklejać klucza prywatnego do komunikatorów, wiadomości e-mail ani zgłoszeń w systemach ticketowych. Klucz publiczny, czyli plik .pub, jest jedyną częścią, którą można udostępniać.

Gdy klucz pozwala na niezawodne logowanie, należy wykonać kolejny krok i wyłączyć uwierzytelnianie hasłem. Dzięki temu próby odgadnięcia hasła do serwera nie będą mogły zakończyć się powodzeniem. Gotowa konfiguracja znajduje się w utwardzanie SSH na VPS.

FAQ

Jak działają klucze SSH bez przesyłania hasła?

Serwer przechowuje klucz publiczny użytkownika w ~/.ssh/authorized_keys. Podczas logowania serwer wysyła wyzwanie, klient podpisuje je kluczem prywatnym, a serwer weryfikuje podpis za pomocą klucza publicznego. Klucz prywatny nigdy nie opuszcza urządzenia, więc nie ma danych do przechwycenia w trakcie transmisji ani informacji, które można ukraść z serwera w celu ponownego wykorzystania. Przejęty serwer ujawnia jedynie klucze publiczne, których nie można użyć do zalogowania się gdziekolwiek indziej.

Czy powinienem używać tego samego klucza SSH dla wszystkich serwerów?

Używanie jednego klucza na wielu serwerach jest poprawne, pod warunkiem że klucz ten znajduje się tylko na jednym urządzeniu. Zasada brzmi: jeden klucz na urządzenie, a nie jeden na serwer. Klucz publiczny z laptopa umieszcza się na każdym serwerze, do którego laptop ma mieć dostęp, a komputer stacjonarny posiada własny, osobny klucz. Upraszcza to unieważnianie dostępu: utrata urządzenia oznacza usunięcie jednej zidentyfikowanej linii z każdego serwera, podczas gdy pozostałe urządzenia nadal działają.

Jakie uprawnienia powinny mieć katalog .ssh oraz plik authorized_keys?

Należy ustawić 700 dla ~/.ssh oraz 600 dla authorized_keys, a także dla każdego klucza prywatnego, których właścicielem jest konto użytkownika. sshd domyślnie działa z włączonym StrictModes yes, więc jeśli plik lub katalog domowy może być modyfikowany przez kogokolwiek innego niż właściciel, serwer zignoruje klucz bez komunikatu, a jedynym śladem będzie Authentication refused: bad ownership or modes w dzienniku autoryzacji lub systemowym journalu serwera.

Jak usunąć klucz SSH z serwera?

Należy usunąć linię z kluczem z pliku ~/.ssh/authorized_keys na koncie, dla którego dostęp został autoryzowany. Odpowiednią linię można znaleźć po komentarzu, czyli etykiecie znajdującej się za danymi klucza. Nowe próby logowania przy użyciu tego klucza zakończą się natychmiastowym niepowodzeniem, jednak już otwarte sesje pozostaną aktywne, dlatego w przypadku kradzieży urządzenia należy również zakończyć wszystkie aktywne sesje. Czynność tę trzeba powtórzyć na każdym serwerze, na który skopiowano klucz.

Czy klucz SSH powinien być zabezpieczony hasłem (passphrase)?

W przypadku klucza na laptopie lub komputerze stacjonarnym – tak. Hasło szyfruje plik klucza, dzięki czemu skradziona lub wyciekła kopia jest bezużyteczna, a ssh-agent pozwala na wpisanie go tylko raz na sesję, zamiast przy każdym połączeniu. Klucze używane przez zautomatyzowane procesy na serwerze zazwyczaj nie posiadają hasła, ponieważ w momencie ich użycia nie ma użytkownika, który mógłby je wpisać. Takie klucze należy chronić poprzez ograniczenie uprawnień konta docelowego.