Zarządzanie kluczami SSH w firmie – jak robić to bezpiecznie

Dlaczego hasła do SSH to zły pomysł

Logowanie do serwera hasłem wydaje się proste, ale w praktyce jest jednym z najsłabszych ogniw bezpieczeństwa infrastruktury. Hasła da się złamać metodą brute force, wykraść przez keylogger albo znaleźć w wycieku z innej usługi, jeśli administrator użył go ponownie. Do tego dochodzi problem współdzielenia – w wielu małych firmach kilku pracowników zna to samo hasło root, co uniemożliwia ustalenie, kto faktycznie wykonał daną operację na serwerze.

Klucze SSH rozwiązują większość tych problemów. Para kluczy (publiczny i prywatny) opiera się na kryptografii asymetrycznej, więc nawet przechwycenie klucza publicznego z serwera nie pozwala zalogować się bez klucza prywatnego, który nigdy nie opuszcza komputera użytkownika. Problem pojawia się jednak wtedy, gdy firma wdraża klucze bez żadnej polityki zarządzania nimi – i to jest temat tego artykułu.

Jak działają klucze SSH w praktyce

Każda para kluczy składa się z klucza prywatnego, który zostaje na stacji roboczej użytkownika i powinien być chroniony hasłem (passphrase), oraz klucza publicznego, który trafia do pliku authorized_keys na serwerze docelowym. Serwer nigdy nie przechowuje sekretu – weryfikuje jedynie, czy użytkownik potrafi wykonać operację kryptograficzną możliwą tylko z odpowiednim kluczem prywatnym.

• RSA – najstarszy i najbardziej rozpowszechniony standard, wymaga długości co najmniej 3072-4096 bitów, by uznać go za bezpieczny
• ECDSA – krótsze klucze, dobra wydajność, ale mniej odporny na błędy implementacyjne niż nowsze algorytmy
• Ed25519 – obecny standard rekomendowany do nowych wdrożeń, szybszy, krótszy i odporny na typowe słabości generatorów losowości

Jeśli firma wciąż generuje klucze RSA 2048 bitów albo starsze DSA, to dobry moment na migrację do Ed25519 przy najbliższej wymianie dostępu.

Wdrożenie kluczy krok po kroku

1. Wygeneruj parę kluczy poleceniem ssh-keygen -t ed25519 -C 'opis-uzytkownika', koniecznie z passphrase chroniącym klucz prywatny
2. Skopiuj klucz publiczny na serwer poleceniem ssh-copy-id lub ręcznie dopisz go do pliku ~/.ssh/authorized_keys użytkownika docelowego
3. Wyłącz logowanie hasłem w pliku sshd_config, ustawiając PasswordAuthentication no – to najważniejszy krok, bez którego klucze są tylko dodatkową, a nie jedyną metodą logowania
4. Ogranicz logowanie roota ustawiając PermitRootLogin prohibit-password albo no, i wymuś logowanie na kontach imiennych z późniejszym sudo
5. Zablokuj słabe algorytmy w konfiguracji demona SSH, pozostawiając tylko Ed25519 i akceptowane warianty RSA

Warto też ograniczyć dostęp firewallem tylko do adresów IP, z których faktycznie łączą się administratorzy, oraz rozważyć zmianę domyślnego portu 22 jako dodatkową warstwę utrudniającą automatyczne skanowanie.

Centralne zarządzanie kluczami zamiast chaosu

Największym problemem nie jest samo generowanie kluczy, tylko brak kontroli nad tym, ile ich krąży po firmie i kto z nich korzysta. Gdy pracownik odchodzi z firmy, jego klucz publiczny często zostaje w plikach authorized_keys na dziesiątkach serwerów, bo nikt nie prowadzi centralnej ewidencji.

• Bastion host (jump server) – jedno centralne wejście do infrastruktury, przez które przechodzi cały ruch SSH, co ułatwia audyt i odcięcie dostępu w jednym miejscu
• SSH Certificate Authority – zamiast rozsyłać klucze publiczne na każdy serwer, urząd certyfikacji podpisuje krótkoterminowe certyfikaty użytkowników, które wygasają automatycznie po kilku godzinach
• Narzędzia PAM – rozwiązania do zarządzania dostępem uprzywilejowanym potrafią wydawać jednorazowe klucze sesyjne i nagrywać sesje administracyjne
• Automatyzacja przez RMM lub Ansible – wdrażanie i usuwanie kluczy publicznych na wielu serwerach jedną komendą zamiast ręcznej edycji plików

Dla małej firmy z kilkoma serwerami wystarczającym krokiem może być prosty rejestr kluczy w arkuszu z datą wydania i właścicielem, ale dla środowisk z dziesiątkami maszyn centralizacja szybko się zwraca w oszczędzonym czasie na audyt.

Rotacja, odwoływanie dostępu i najczęstsze błędy

Klucz SSH bez daty ważności to potencjalny dostęp na lata, nawet jeśli pracownik dawno zmienił dział albo opuścił firmę. Dlatego rotacja i szybkie odwoływanie dostępu powinny być elementem standardowego procesu offboardingu, obok wyłączania konta w Active Directory czy Microsoft 365.

• Brak passphrase na kluczu prywatnym – jeśli laptop administratora zostanie skradziony, klucz bez hasła daje natychmiastowy dostęp do serwerów
• Kopiowanie tego samego klucza prywatnego między wieloma urządzeniami zamiast wygenerowania osobnej pary dla każdego
• Zapominanie o starych kluczach w authorized_keys po zmianie zespołu albo zakończeniu współpracy z kontraktorem
• Brak logowania i monitoringu – bez centralnego zapisu sesji trudno ustalić, kto i kiedy logował się na serwer produkcyjny

Dobrą praktyką jest przegląd plików authorized_keys na wszystkich serwerach co kwartał oraz wpisanie tego punktu do polityki bezpieczeństwa firmy, tak samo jak przeglądu uprawnień w Active Directory.