Zarządzanie kluczami SSH w praktyce

Jak działają klucze SSH

Klucz SSH składa się z pary plików: klucza prywatnego, który pozostaje na urządzeniu, oraz klucza publicznego, który należy skopiować na każdy serwer przeznaczony do logowania. Podczas nawiązywania połączenia serwer wykorzystuje klucz publiczny do wysłania wyzwania, na które odpowiedź może podać wyłącznie pasujący klucz prywatny. Klucz prywatny nigdy nie opuszcza urządzenia, dzięki czemu żadne dane poufne nie są przesyłane przez sieć, a przejęty serwer nie zawiera żadnych użytecznych danych do kradzieży. Z tego powodu klucze są bezpieczniejsze od haseł. Skuteczne zarządzanie kluczami SSH opiera się na czterech zasadach: jeden klucz na jedno urządzenie, odpowiednie uprawnienia plików wymagane przez sshd, plik ~/.ssh/config w celu uniknięcia wpisywania opcji oraz umiejętność usunięcia klucza w przypadku zgubienia laptopa.

Niniejszy poradnik opisuje każdą zasadę w systemie Ubuntu 24.04, jednak większość informacji dotyczy dowolnego serwera Linux oraz każdej nowszej wersji OpenSSH.

Przed rozpoczęciem należy wyjaśnić terminologię, aby uniknąć błędów. Klucz publiczny nie jest poufny. Można go wkleić do zgłoszenia technicznego, wysłać e-mailem lub opublikować; nie pozwala on nikomu na logowanie. Kluczem poufnym jest klucz prywatny. Każda osoba, która skopiuje ten plik i zna jego hasło (jeśli jest ustawione), jest traktowana przez serwery jako użytkownik.

Tworzenie klucza: ed25519 jest zalecanym standardem

Na własnym komputerze, a nie na serwerze, należy wykonać polecenie:

ssh-keygen -t ed25519 -C "laptop"

Parametr -t ed25519 określa typ klucza. Ed25519 to nowoczesny standard: klucze są krótkie, szybkie i obsługiwane przez każdą wersję OpenSSH od 2014 roku. Należy użyć ssh-keygen -t rsa -b 4096 tylko w przypadku konieczności połączenia się ze starym urządzeniem, które nie obsługuje ed25519. Parametr -C "laptop" służy do dodania komentarza. Komentarz nie pełni funkcji kryptograficznych, ale ułatwia identyfikację klucza w pliku authorized_keys serwera w przyszłości; zaleca się wpisanie nazwy urządzenia, na którym znajduje się klucz.

Parametr ssh-keygen określa lokalizację zapisu klucza. Należy zaakceptować domyślną ścieżkę ~/.ssh/id_ed25519. Następnie system poprosi o podanie hasła (passphrase). Należy je ustawić; sekcja dotycząca hasła poniżej wyjaśnia, dlaczego nie wpływa ono na codzienną pracę. Wynikiem operacji są dwa pliki: ~/.ssh/id_ed25519 to klucz prywatny, a ~/.ssh/id_ed25519.pub to klucz publiczny. Zawartość klucza publicznego przedstawia poniżej:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Klucz publiczny składa się z jednej linii zawierającej typ klucza, dane klucza oraz komentarz. Ta linia jest zapisywana na serwerach.

Jeden klucz na urządzenie, a nie jeden na serwer

Podstawowe pytanie brzmi: czy wymagany jest nowy klucz dla każdego serwera? Nie. Należy utworzyć jeden klucz dla każdego urządzenia, z którego podejmowane są operacje, a następnie umieścić ten sam klucz publiczny na każdym serwerze, do którego urządzenie musi mieć dostęp. Klucz służy do identyfikacji urządzenia. Plik authorized_keys na każdym serwerze zawiera listę dopuszczonych urządzeń.

Ten model zapewnia skalowalność, podczas gdy alternatywne podejścia wykazują przewidywalne błędy. Model „jeden klucz na serwer” oznacza, że laptop obsługujący dwadzieścia serwerów przechowuje dwadzieścia kluczy private, co prowadzi do utraty kontroli nad ich identyfikacją. Model „jeden wspólny klucz dla wszystkich urządzeń” jest gorszy: w przypadku kradzieży laptopa nie można unieważnić tylko tego urządzenia bez jednoczesnego zablokowania komputera stacjonarnego. Ponieważ oba urządzenia posiadają ten sam klucz private, konieczna jest wymiana klucza w całej infrastrukturze i jednoczesna redystrybucja na wszystkie urządzenia.

W modelu „jeden klucz na urządzenie” utrata laptopa skutkuje koniecznością usunięcia tylko jednej linii na każdym serwerze: należy usunąć wpis dotyczący laptopa z pliku authorized_keys, a wszystkie pozostałe urządzenia nadal będą działać. Komentarz ustawiony za pomocą -C umożliwia szybką lokalizację właściwego wpisu.

Zasada tego modelu: klucz private jest generowany na urządzeniu i zostaje z nim na stałe. Nie należy kopiować klucza private na drugą maszynę ani przesyłać go na serwer. W przypadku konieczności nadania dostępu nowemu urządzeniu, należy wygenerować na nim nowy klucz.

Umieszczenie klucza publicznego na serwerze

Najprostszym sposobem jest użycie ssh-copy-id, który jest częścią pakietu OpenSSH:

ssh-copy-id matt@10.0.0.10

Narzędzie to łączy się przy użyciu dostępnej metody logowania (zazwyczaj hasła), dopisuje klucz publiczny do pliku ~/.ssh/authorized_keys na serwerze oraz tworzy katalog i plik z odpowiednimi uprawnieniami, jeśli nie istnieją. Należy to przetestować, otwierając nową sesję SSH: serwer powinien umożliwić logowanie bez żądania hasła użytkownika. Jeśli klucz posiada passphrase, lokalna maszyna może o niego zapytać; jest to zapytanie lokalne, a nie hasło do serwera.

W przypadku gdy logowanie za pomocą hasła jest już wyłączone, ssh-copy-id nie może nawiązać połączenia, dlatego należy dodać wpis ręcznie. Należy zalogować się za pomocą działającej sesji lub konsoli webowej dostawcy, a następnie wykonać na serwerze 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ć właściwy klucz publiczny (pełną linię z id_ed25519.pub). Format authorized_keys to jeden klucz publiczny w jednej linii; stanowi to całą bazę danych dostępu. Dodanie urządzenia polega na dopisaniu linii, a odebranie dostępu polega na jej usunięciu. Na nowym serwerze ten krok należy wykonać w ramach pierwszych 10 minut na nowym VPS, bezpośrednio przed wyłączeniem logowania za pomocą hasła.

Uprawnienia powodujące błędy logowania przy użyciu klucza

Jest to najczęstsza przyczyna niepowodzenia logowania kluczem. Błąd występuje bez powiadomienia po stronie klienta. W systemie Ubuntu 24.04 proces sshd domyślnie działa z flagą StrictModes yes, co oznacza odmowę użycia pliku authorized_keys, który może być edytowany przez innych użytkowników. Jeśli plik, katalog ~/.ssh lub katalog domowy posiadają uprawnienia do zapisu dla innych użytkowników, sshd ignoruje klucz i przechodzi do żądania hasła bez podawania przyczyny w kliencie. (OpenSSH w systemie Ubuntu dopuszcza jeden wyjątek: plik z uprawnieniami do zapisu dla grupy prywatnej użytkownika, w której nie ma nikogo innego. Nie należy na tym polegać; należy stosować poniższe ustawienia trybu.) Przyczyna błędu pojawia się wyłącznie w logach serwera:

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

Na minimalnych obrazach bez rsyslog brak jest usługi auth.log; ta sama linia znajduje się w journalu: sudo journalctl -u ssh | grep 'Authentication refused'.

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

Rozwiązaniem jest zmiana uprawnień oraz sprawdzenie własności, należy wykonać na serwerze jako użytkownik dotknięty problemem:

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

Zasada do zapamiętania: 700 dla katalogu .ssh oraz 600 dla wszystkich elementów wewnątrz niego. Te same wartości należy zastosować na własnym komputerze, ponieważ klient również wykonuje weryfikację. Klucz prywatny dostępny do odczytu dla innych użytkowników powoduje, że ssh całkowicie odrzuca klucz, a tym razem błąd jest zgłaszany wprost:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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: uniknięcie powtarzalnego wpisywania opcji

Plik ~/.ssh/config na lokalnym komputerze przypisuje każdemu serwerowi krótką nazwę i przechowuje powtarzalne opcje. 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 procesy odczytują ten plik. HostName to rzeczywisty adres, User eliminuje konieczność wpisywania nazwy użytkownika, a IdentityFile określa, który klucz ma zostać użyty.

Warto wspomnieć o IdentitiesOnly yes, ponieważ rozwiązuje on częsty problem. Gdy agent przechowuje wiele kluczy, klient oferuje je jeden po drugim, a serwer traktuje każdą próbę jako nieudaną. Przy dużej liczbie załadowanych kluczy występuje Received disconnect: Too many authentication failures przed podjęciem próby użycia właściwego klucza. Użycie IdentitiesOnly yes sprawia, że klient oferuje wyłącznie klucz wskazany w IdentityFile, co zapobiega wystąpieniu błędu.

Passphrases i ssh-agent

Hasło (passphrase) szyfruje plik klucza prywatnego na dysku. Bez hasła każdy, kto skopiuje plik, może go natychmiast użyć. Dzięki hasłu skradziony plik jest bezużyteczny, dopóki hasło nie zostanie odgadnięte. W przypadku klucza na laptopie jest to pożądana ochrona, ponieważ laptopy są często kradzione, a kopie zapasowe wyciekają.

Brak kosztów operacyjnych związanych z używaniem hasła wynika z ssh-agent. Agent przechowuje odszyfrowany klucz w pamięci RAM, dzięki czemu 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 posiada uruchomiony agent w tle. Aby załadować klucz do agenta, należy użyć:

ssh-add ~/.ssh/id_ed25519

Polecenie ssh-add -l wyświetla klucze przechowywane obecnie przez agenta. Uwaga: przekazywanie agenta (ssh -A) pozwala zdalnemu serwerowi na używanie agenta do dalszej autentykacji podczas trwania połączenia. Funkcję tę należy włączać tylko dla serwerów, którym w pełni się ufa, i domyślnie pozostawiać wyłączoną.

Rotacja i unieważnianie: procedura w przypadku zgubionego laptopa

Unieważnienie zwykłego klucza SSH polega na usunięciu jego linii z pliku authorized_keys na każdym serwerze, na którym ten klucz jest zarejestrowany. Nie ma potrzeby powiadamiania urzędu certyfikacji ani czekania na upływ terminu ważności. Po usunięciu linii nowe logowania przy użyciu tego klucza zostaną odrzucone.

Należy przeprowadzić procedurę teraz, zanim wystąpi sytuacja awaryjna. Wybrać serwer, otworzyć ~/.ssh/authorized_keys i odnaleźć klucz po jego komentarzu. Usunąć linię za pomocą edytora lub przefiltrować ją po komentarzu:

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

Następnie należy potwierdzić z urządzenia, z którego unieważniono dostęp, że logowanie nie powiodło się, oraz z innego urządzenia, że logowanie nadal działa. Należy pamiętać, że usunięcie klucza nie zamyka aktywnych sesji, ponieważ klucz jest sprawdzany wyłącznie podczas logowania. W przypadku unieważniania dostępu dla skradzionego urządzenia należy również sprawdzić who na serwerze i zakończyć wszystkie nieznane sesje.

Rotacja to ta sama operacja, lecz wykonana w innej kolejności: należy wygenerować nowy klucz na urządzeniu, zainstalować go za pomocą ssh-copy-id, potwierdzić możliwość logowania nowym kluczem, a następnie usunąć starą linię. Operację tę należy wykonać przy zmianie właściciela urządzenia, w przypadku podejrzenia ujawnienia klucza lub gdy pracownik opuszcza zespół. Ręczne wykonywanie tych czynności na dwóch serwerach jest dopuszczalne; w przypadku dwudziestu serwerów wymagana jest automatyzacja, a zarządzanie wieloma serwerami Linux wyjaśnia, jak wymusić ten sam stan authorized_keys na całej flocie urządzeń.

Czego nie należy robić

• Nie należy używać tego samego klucza private na wszystkich urządzeniach. Uniemożliwia to unieważnienie skradzionego urządzenia bez konieczności wymiany klucza na wszystkich pozostałych maszynach.

• Nie należy przesyłać klucza private do repozytorium git, nawet prywatnego. Automatyczne skanery monitorują publiczne repozytoria i próbują użyć wyciekłych kluczy w ciągu kilku minut od operacji push. Dodatkowo, repozytorium zmienione później na publiczne ujawnia całą historię zmian.

• Nie należy przesyłać klucza private z laptopa na serwer w celu nawiązania połączenia między serwerami. Należy wygenerować osobny klucz bezpośrednio na serwerze i autoryzować go tylko tam, gdzie jest to wymagane.

• Nie należy wklejać klucza private na czacie, w wiadomościach e-mail lub w zgłoszeniach (ticketach). Jedynym elementem przeznaczonym do udostępniania jest klucz publiczny, czyli plik .pub.

Po uzyskaniu niezawodnego logowania za pomocą klucza, należy wyłączyć uwierzytelnianie hasłem. Zapobiegnie to skutecznym próbom odgadnięcia hasła przez osoby nieuprawnione. Gotowa konfiguracja znajduje się w SSH hardening on a VPS.

FAQ

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

Serwer przechowuje klucz publiczny w ~/.ssh/authorized_keys. Podczas logowania serwer wysyła wyzwanie, klient podpisuje wyzwanie kluczem prywatnym, a serwer weryfikuje podpis kluczem publicznym. Klucz prywatny nigdy nie opuszcza urządzenia, więc nie można go przechwycić podczas transmisji ani ukraść z serwera. Przejęty serwer ujawnia jedynie klucze publiczne, których nie można wykorzystać do logowania w innych miejscach.

Czy należy używać tego samego klucza SSH na wszystkich serwerach?

Używanie jednego klucza na wielu serwerach jest poprawne, pod warunkiem że klucz ten znajduje się na jednym urządzeniu. Zasadą jest jeden klucz na urządzenie, a nie jeden na serwer: klucz publiczny laptopa należy umieścić na każdym serwerze, do którego laptop ma dostęp, natomiast komputer stacjonarny powinien posiadać własny klucz. Pozwala to na prostą unieważnienie dostępu, ponieważ utrata urządzenia wymaga usunięcia tylko jednej linii z każdego serwera, a 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 oraz dla każdego klucza prywatnego. Właścicielem plików musi być konto, które ich używa. Usługa sshd domyślnie działa z uprawnieniami StrictModes yes, więc plik lub katalog domowy z uprawnieniami do zapisu dla innych użytkowników spowoduje ciche zignorowanie klucza. Jedynym śladem będzie wpis Authentication refused: bad ownership or modes w logach uwierzytelniania serwera lub w journalu.

Jak usunąć klucz SSH z serwera?

Należy usunąć linię odpowiadającą kluczowi z pliku ~/.ssh/authorized_keys w koncie, dla którego klucz był autoryzowany. Właściwą linię należy zidentyfikować po komentarzu znajdującym się po danych klucza. Nowe próby logowania przy użyciu tego klucza zostaną natychmiast odrzucone, ale trwające sesje pozostaną otwarte. W przypadku kradzieży urządzenia należy również zakończyć wszystkie aktywne sesje dla tego urządzenia. Operację należy powtórzyć na każdym serwerze, na którym skopiowano klucz.

Czy klucz SSH powinien posiadać passphrase?

W przypadku klucza na laptopie lub komputerze stacjonarnym – tak. Passphrase szyfruje plik klucza, dzięki czemu skopiowany lub wycieknięty plik jest bezużyteczny. Użycie ssh-agent oznacza konieczność wpisania hasła raz na sesję, zamiast przy każdym połączeniu. Klucze używane przez automatyzację bez nadzoru na serwerze zazwyczaj nie mają passphrase, ponieważ nie ma użytkownika, który mógłby je wpisać; należy je zabezpieczyć poprzez ograniczenie uprawnień konta docelowego.