logowanie kluczem SSH

Logowanie kluczem SSH to uwierzytelnianie na serwerze przez SSH lub SFTP za pomocą pary kluczy zamiast hasła. Klucz publiczny trafia na serwer, a klucz prywatny zostaje na komputerze administratora. Standard protokołu SSH mówi, że w tej metodzie uwierzytelnieniem jest samo posiadanie klucza prywatnego: klient wysyła podpis utworzony tym kluczem, a serwer go sprawdza ^[1]. Metoda jest obowiązkowa dla każdej implementacji SSH ^[1].

Jak działa

Klucz publiczny i prywatny to para kluczy kryptograficznych: to, co podpisze klucz prywatny, można zweryfikować kluczem publicznym, ale z publicznego nie da się odtworzyć prywatnego. Serwer sprawdza dwie rzeczy: czy przedstawiony klucz jest dopuszczony dla danego konta i czy podpis jest poprawny; jeśli oba warunki są spełnione, logowanie się udaje, w przeciwnym razie musi zostać odrzucone ^[1]. Hasło w ogóle nie przechodzi przez sieć, więc nie ma czego podsłuchać ani zgadywać.

RYS. 1Logowanie kluczem publicznym

W serwerze OpenSSH listę dopuszczonych kluczy przechowuje plik wskazany w opcji AuthorizedKeysFile; domyślnie jest to .ssh/authorized_keys w katalogu domowym użytkownika ^[2]. Parę kluczy tworzy narzędzie ssh-keygen; uruchomione bez argumentów generuje klucz typu Ed25519 i zapisuje prywatny w ~/.ssh/id_ed25519 ^[3].

ssh-keygen -t ed25519 -C "admin@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub uzytkownik@example.com

Klucz prywatny można zaszyfrować frazą (passphrase). Dokumentacja ssh-keygen opisuje ją jako hasło, które może być całym zdaniem z dowolnymi znakami, i zaleca od 10 do 30 znaków ^[3]. Fraza jest przetwarzana funkcją wyprowadzania klucza bcrypt_pbkdf; domyślnie 24 rundy, a więcej rund utrudnia zgadywanie frazy kosztem wolniejszego odblokowania ^[3].

Hasło a klucz

NIST podkreśla, że uwierzytelnianie kluczem publicznym nie tworzy ukrytych relacji zaufania: kto ma dostęp, widać po zawartości pliku na serwerze docelowym ^[4]. Dla automatycznego dostępu, na przykład skryptów wdrożeniowych, jest to zalecana metoda, bo pozwala ograniczyć klucz do adresu źródłowego i jednego polecenia ^[4].

W WordPressie

WordPress sam nie loguje przez SSH, ale administrator zarządza przez SSH lub SFTP plikami strony, bazą i narzędziami wiersza poleceń. Dokumentacja WordPressa zaleca SFTP zamiast FTP, bo przy SFTP hasło i dane są szyfrowane w drodze do serwera ^[6]. Logowanie kluczem idzie o krok dalej: hasła nie ma wcale.

Na hostingu z panelem klucz dodaje się zwykle w panelu. Instrukcja cyber_Folks opisuje dwie drogi: skopiowanie klucza publicznego do pliku authorized_keys z uprawnieniami 600 albo wklejenie go w sekcji „Klucze SSH” panelu DirectAdmin ^[5]. Po tym kroku, jak pisze instrukcja, powinno być możliwe logowanie do serwera bez użycia hasła ^[5].

Dla stron WordPress klucz SSH chroni najcenniejszy dostęp. Kto przejmie konto SSH, może podmienić pliki rdzenia i wtyczek, wgrać webshell albo odczytać wp-config.php z hasłem do bazy. Hasło do SSH bywa celem ataków siłowych (brute-force) i credential stuffingu; klucz eliminuje obie metody.

Zagrożenia i skutki

Klucz przenosi ryzyko z hasła na plik. NIST wskazuje, że skradziony, wyciekły albo niecofnięty klucz prywatny jest równie groźny jak skradzione hasło: może go użyć każdy, kto skopiował go z komputera, z kopii zapasowej (backup) albo przez złośliwe oprogramowanie, na przykład infostealer ^[4]. Po przejęciu konta atakujący może czytać i zmieniać wszystkie dane tego użytkownika ^[4].

Drugim ryzykiem są klucze-furtki. NIST opisuje, że wystarczy wygenerować nową parę i dopisać klucz publiczny do pliku authorized_keys; takie pliki często nie są audytowane, więc dopisany klucz może pozostać niezauważony latami ^[4]. Dlatego po każdym włamaniu na serwer trzeba przejrzeć te pliki, a nie tylko zmienić hasła.

Trzecim ryzykiem są klucze bez frazy. NIST zauważa, że klucze używane do dostępu automatycznego są zwykle zapisane jako niezaszyfrowane pliki, bo nie ma nikogo, kto wpisałby frazę; ponieważ dają dostęp do serwerów, są danymi wrażliwymi ^[4]. Taki plik na laptopie wykonawcy albo w repozytorium projektu jest równoważny zapisanemu hasłu do serwera. Podobnie klucze byłych współpracowników, których nikt nie usunął z serwera, zostawiają otwarte drzwi, dopóki ktoś nie sprawdzi zawartości authorized_keys.

Jak się bronić

• Wyłączyć logowanie hasłem. W OpenSSH opcja PasswordAuthentication ma domyślnie wartość yes ^[2]; po wgraniu i sprawdzeniu klucza warto ustawić no, podobnie KbdInteractiveAuthentication ^[2].
• Nie logować się hasłem na konto root. Domyślna wartość PermitRootLogin to prohibit-password, która wyłącza dla roota logowanie hasłem ^[2].
• Ograniczyć konta. Opcja AllowUsers dopuszcza logowanie tylko użytkownikom pasującym do wzorców ^[2].
• Chronić klucz prywatny frazą. NIST zaleca frazę dla kluczy używanych przez ludzi i ustalenie zasad jej siły ^[4].
• Prowadzić inwentarz. NIST zaleca spis kluczy i relacji zaufania, usuwanie osieroconych wpisów i rotację kluczy ^[4].
• Dołożyć warstwę sieciową, na przykład fail2ban albo białą listę adresów IP (allowlist) dla portu SSH.

Historia

Metoda klucza publicznego jest częścią protokołu uwierzytelniania SSH opisanego w RFC 4252 ze stycznia 2006 roku ^[1]. W październiku 2015 roku NIST wydał raport NISTIR 7966 o zarządzaniu dostępem przez SSH, który zwraca uwagę, że klucze SSH w dużych organizacjach często dają bardzo wysokie uprawnienia, a ich zarządzanie było dotąd zaniedbywane ^[4].