Gdzie są przechowywane klucze SSH w systemie Linux — i jak zarządzać nimi bezpiecznie

SSH (Secure Shell) jest podstawowym narzędziem w ekosystemie Linux, używanym do zdalnego dostępu, bezpiecznych transferów plików, automatyzacji i zarządzania serwerem. Chociaż większość użytkowników korzysta z SSH za pomocą polecenia ssh, w tle SSH opiera się na parach kluczy publicznych i prywatnych do uwierzytelniania — szczególnie w środowiskach, gdzie logowanie bez hasła, automatyzacja i praktyki DevOps są niezbędne.

Domyślna lokalizacja przechowywania kluczy SSH

Najczęściej klucze SSH są przechowywane w:

Odnosi się to do katalogu .ssh w folderze domowym użytkownika, np.:

Typowe pliki w tym katalogu:

Plik	Cel
id_rsa	Domyślny klucz prywatny (RSA)
id_rsa.pub	Pasujący klucz publiczny
id_ecdsa, id_ed25519	Inne klucze prywatne (ECDSA, Ed25519)
id_*.pub	Odpowiednie klucze publiczne
authorized_keys	Przechowuje klucze publiczne dozwolone do połączenia
known_hosts	Przechowuje odciski palców serwera (weryfikacja klucza hosta)
config	Konfiguracja klienta SSH specyficzna dla użytkownika

Jeśli generujesz klucze za pomocą ssh-keygen, są one domyślnie przechowywane tutaj, chyba że określono inną ścieżkę.

Lokalizacje kluczy SSH w systemie

Klucze hosta serwera SSH (sshd)

Klucze systemowe używane przez demon SSH (po stronie serwera):

Typowe pliki:

Plik	Cel
ssh_host_rsa_key	Klucz prywatny hosta (RSA)
ssh_host_rsa_key.pub	Klucz publiczny hosta
ssh_host_ecdsa_key	Klucz prywatny hosta ECDSA
ssh_host_ed25519_key	Klucz prywatny hosta Ed25519

Te klucze są używane do identyfikacji serwera dla klientów, a nie do uwierzytelniania użytkowników.

Demon SSH (sshd) przedstawia klucz publiczny hosta podczas połączenia; klienci porównują go z ~/.ssh/known_hosts.

Niestandardowe lokalizacje kluczy

Możesz generować lub używać kluczy SSH z dowolnej lokalizacji, ale musisz określić ścieżkę:

Możesz również skonfigurować wiele kluczy za pomocą ~/.ssh/config:

Gdzie są używane klucze?

Wychodzące (po stronie klienta)

Klienci SSH domyślnie szukają kluczy prywatnych w ~/.ssh/. Służą one do inicjowania uwierzytelniania podczas łączenia się z zdalnym serwerem.

ssh, scp, rsync przez SSH, git (gdy używasz zdalnego SSH)

📌 Przychodzące (po stronie serwera)

Serwer szuka kluczy publicznych w:

Ten plik zawiera listę, które klucze publiczne są dozwolone do logowania do konkretnego konta użytkownika.

Jeśli user_a próbuje połączyć się z serwerem jako user_b, ich klucz publiczny musi być obecny w ~user_b/.ssh/authorized_keys.

Uprawnienia — kluczowe dla bezpieczeństwa

Poprawne uprawnienia:

Niepoprawne uprawnienia mogą spowodować, że SSH zignoruje twoje klucze lub całkowicie odrzuci logowania.

Zarządzanie kluczami SSH w sposób bezpieczny

Użyj frazy hasła podczas generowania kluczy prywatnych:
ssh-keygen -t ed25519 -C "your_email@example.com"
Użyj ssh-agent do przechowywania odblokowanych kluczy w pamięci:
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa
Regularnie zmieniaj klucze
Usuń nieużywane lub osierocone klucze z “authorized_keys”
Używaj oddzielnych kluczy dla każdego hosta/projektu
Unikaj używania kluczy root w różnych środowiskach

Audyt i debugowanie

Aby zobaczyć, jaki klucz jest używany podczas połączenia SSH:

To drukuje szczegółowe logi, w tym, który plik tożsamości był próbowany.

Aby wylistować załadowane klucze w aktualnym agencie:

Aby usunąć klucz:

Podsumowanie

Zrozumienie, gdzie klucze SSH są przechowywane w systemie Linux — oraz jak nimi zarządzać w sposób bezpieczny — jest kluczowe dla administratorów systemów, programistów, inżynierów DevOps i każdego, kto pracuje w środowiskach wielohostowych lub wieloużytkownikowych.

Znając różnicę między kluczami użytkowników, kluczami hostów i kluczami autoryzowanymi, możesz:

Rozwiązywać problemy z uwierzytelnianiem
Ustawić bezpieczne zautomatyzowane przepływy pracy
Zarządzać dostępem w zespołach i systemach

W systemach produkcyjnych lub na platformach chmurowych (np. VPS lub serwery dedykowane), niewłaściwe zarządzanie kluczami SSH może prowadzić do poważnych luk w zabezpieczeniach. Upewnij się, że przestrzegasz najlepszych praktyk i regularnie audytujesz dostęp.