Klucze SSH | IWOFR

Klucz SSH jest poświadczeniem dostępu w protokole SSH. Jego funkcja jest podobna do nazwy użytkownika i hasła, ale klucze są głównie używane w zautomatyzowanych procesach oraz do wdrażania pojedynczego logowania przez administratorów systemu i zaawansowanych użytkowników.

Klucze SSH są poświadczeniami uwierzytelniającymi

SSH (Secure Shell) jest używany do zarządzania sieciami, systemami operacyjnymi i konfiguracjami. Znajduje się również w wielu narzędziach do transferu plików i zarządzania konfiguracją. Używa go każda duża korporacja, w każdym centrum danych.

KluczeSSH umożliwiają automatyzację, która czyni nowoczesne usługi w chmurze i inne usługi zależne od komputera możliwymi i opłacalnymi. Oferują wygodę i zwiększone bezpieczeństwo, gdy są odpowiednio zarządzane.

Funkcjonalnie klucze SSH przypominają hasła. Umożliwiają dostęp i kontrolę nad tym, kto ma do czego dostęp. W zarządzaniu tożsamością i dostępem, wymagają one podobnych zasad, dostarczania i zamykania jak konta użytkowników i hasła. Nie można zapewnić poufności, integralności ani żadnej gwarancji ciągłej dostępności systemów bez kontroli kluczy SSH.

Technicznie klucze są kluczami kryptograficznymi wykorzystującymi kryptosystem klucza publicznego. Jednak funkcjonalnie są to poświadczenia uwierzytelniające i muszą być zarządzane jako takie.

Autoryzowane klucze określają, kto może uzyskać dostęp do każdego systemu

Autoryzowane klucze są kluczami publicznymi, które przyznają dostęp. Są one analogiczne do zamków, które można otworzyć odpowiednim kluczem prywatnym.

Więcej informacji na ten temat znajduje się na dedykowanej stronie poświęconej kluczom autoryzowanym.

Klucze tożsamości identyfikują użytkowników i zapewniają dostęp

Klucze tożsamości są kluczami prywatnymi, których klient SSH używa do uwierzytelnienia się podczas logowania do serwera SSH. Są one analogiczne do kluczy fizycznych, które mogą otworzyć jeden lub więcej zamków.

Klucze autoryzowane i klucze tożsamości są wspólnie nazywane kluczami użytkownika. Odnoszą się one do uwierzytelniania użytkownika, w przeciwieństwie do kluczy hosta, które są używane do uwierzytelniania hosta.

Więcej informacji na ten temat można znaleźć na dedykowanej stronie poświęconej kluczom tożsamości.

Uwierzytelnianie użytkownika oparte na certyfikatach

Certyfikaty PKI mogą być również używane do uwierzytelniania. W tym przypadku użytkownik nadal posiada klucz prywatny, ale również certyfikat powiązany z tym kluczem. Technologia ta jest wspierana zarówno w Tectia SSH jak i OpenSSH, z pewnymi różnicami. Więcej informacji można znaleźć na dedykowanej stronie poświęconej uwierzytelnianiu opartemu na certyfikatach w SSH.

Klucze uwierzytelniające urządzenia

Klucze hosta uwierzytelniają serwery

Klucze hosta służą do uwierzytelniania hostów, czyli komputerów. Ich celem jest zapobieganie atakom typu man-in-the-middle. Zobacz osobną stronę na temat kluczy hostów, aby uzyskać więcej informacji.

Uwierzytelnianie hostów oparte na certyfikatach może być bardzo atrakcyjną alternatywą w dużych organizacjach. Pozwala ono na rotację kluczy uwierzytelniających urządzenia i wygodne zarządzanie nimi, a także na zabezpieczenie każdego połączenia.

Znane klucze hostów

Jedną z unikalnych cech SSH jest to, że domyślnie ufa i zapamiętuje klucz hosta przy pierwszym połączeniu z nim. W 1995 roku nie istniała żadna scentralizowana infrastruktura kluczy dla hostów, a dziś (2017) nadal jej nie ma, z wyjątkiem certyfikatów SSL dla serwerów WWW. Łatwość wdrożenia była jednym z głównych powodów, dla których SSH odniosło sukces.

Zapamiętane klucze hostów nazywane są znanymi kluczami hostów i są przechowywane w pliku o nazwie known_hosts w OpenSSH. Tak długo jak klucze hostów się nie zmieniają, to podejście jest bardzo proste w użyciu i zapewnia dość dobre bezpieczeństwo. Jednak w dużych organizacjach, gdy klucze się zmieniają, utrzymywanie plików znanych hostów może stać się bardzo czasochłonne. W takim przypadku zalecane jest użycie certyfikatów dla kluczy hostów. Tectia SSH obsługuje standardowe certyfikaty X.509 dla hostów. OpenSSH ma swój własny, zastrzeżony format certyfikatów. Zaletą standardowych certyfikatów jest to, że mogą być wydane przez dowolny urząd certyfikacji (CA), podczas gdy dla kluczy OpenSSH nie istnieją wiarygodne CA. Zobacz dedykowaną stronę poświęconą certyfikatom w SSH, aby uzyskać więcej informacji.

Klucze sesji

Klucz sesji w SSH jest kluczem szyfrującym używanym do szyfrowania większości danych w połączeniu. Klucz sesji jest negocjowany podczas połączenia, a następnie używany z symetrycznym algorytmem szyfrowania i algorytmem szyfrowania wiadomości w celu ochrony danych. Więcej informacji znajdziesz na osobnej stronie poświęconej kluczom sesji.

Jak skonfigurować uwierzytelnianie oparte na kluczach

Uwierzytelnianie oparte na kluczach w SSH jest nazywane uwierzytelnianiem kluczem publicznym. W domyślnej konfiguracji jest ono łatwe do skonfigurowania przez użytkowników końcowych. Z drugiej strony, organizacje dbające o bezpieczeństwo muszą ustalić jasne zasady przyznawania i odbierania dostępu opartego na kluczach.

Jak skonfigurować uwierzytelnianie oparte na kluczach publicznych dla OpenSSH

Klucze SSH są zazwyczaj konfigurowane w pliku authorized_keys w podkatalogu .ssh w katalogu domowym użytkownika. Zazwyczaj administrator systemu najpierw tworzy klucz za pomocą ssh-keygen, a następnie instaluje go jako autoryzowany klucz na serwerze za pomocą narzędzia ssh-copy-id. Zobacz również dedykowaną stronę na temat konfiguracji kluczy autoryzowanych dla OpenSSH.

Zalecamy używanie passphrase dla wszystkich kluczy tożsamości używanych do interaktywnego dostępu. W zasadzie zalecamy używanie passphrases również dla automatycznego dostępu, ale często nie jest to praktyczne.

Przechowywanie kluczy w ssh-agent dla pojedynczego logowania

SSH posiada program o nazwie ssh-agent, który może przechowywać w pamięci odszyfrowane klucze prywatne użytkownika i używać ich do uwierzytelniania logowań. Agent może być również użyty do uzyskania dostępu do kluczy na karcie chipowej lub w Hardware Security Module (HSM). Zobacz dokumentację dla ssh-agent, aby dowiedzieć się, jak go skonfigurować.

Połączenie z agentem SSH może być przekierowane na serwer, tak aby pojedyncze logowanie działało również od tego serwera. Ta funkcja powinna być używana ostrożnie, ponieważ pozwala skompromitowanemu serwerowi na użycie danych uwierzytelniających użytkownika z oryginalnego agenta. Przekazywanie agenta może jednak stanowić duże ułatwienie dla zaawansowanych użytkowników w środowiskach o mniejszym znaczeniu dla bezpieczeństwa.

Aby włączyć przekazywanie agenta, ustaw AllowAgentForwarding na yes w pliku /etc/ssh/sshd_config na serwerze i ForwardAgent na yes w pliku konfiguracyjnym klienta /etc/ssh/ssh_config.

Zalecane rozmiary kluczy

Zalecamy wybór rozmiarów kluczy zgodnie z NIST SP 800-57. Domyślne rozmiary kluczy używane przez narzędzie ssh-keygen mają ogólnie akceptowalną siłę. W rzeczywistości, ponieważ protokół nigdy nie ujawnia kluczy publicznych, które są akceptowane do uwierzytelniania użytkownika, algorytmy używane do kluczy nie są tak krytyczne, jak na przykład w certyfikatach PKI.

Dla kluczy RSA, 2048 bitów jest prawdopodobnie dobrym wyborem dzisiaj (2017). Jednak wielu kryptografów zaleca obecnie przejście na klucze ECDSA i uważa, że postępy w faktoryzacji dużych liczb całkowitych mogą sprawić, że klucze RSA będą podatne na ataki w najbliższej/średniej przyszłości. Dla ECDSA zalecamy używanie 521 bitowych (sic!) kluczy, mimo że 384 lub nawet 256 bitowe klucze prawdopodobnie byłyby bezpieczne. Po prostu nie ma praktycznych korzyści z używania mniejszych kluczy.

Lokalizacja klucza tożsamości

Klucze tożsamości są zwykle przechowywane w katalogu użytkownika .ssh, na przykład, .ssh/ssh_id_rsa. Domyślna nazwa pliku z kluczem tożsamości zaczyna się od id_<algorithm>. Można jednak podać dowolną nazwę pliku i dowolną lokalizację podczas tworzenia klucza prywatnego, podając nazwę ścieżki za pomocą opcji -i do klienta SSH. Na przykład, ssh -i /home/ylo/secure/my-key [email protected] użyłby klucza prywatnego z pliku my-key do uwierzytelnienia.

Domyślna lokalizacja klucza tożsamości może być również skonfigurowana w pliku /etc/ssh/ssh_config lub w pliku użytkownika .ssh/config przy użyciu opcji IdentityFile.

Lokalizacja autoryzowanego klucza

Gdy użytkownik próbuje się zalogować używając uwierzytelniania opartego na kluczach, serwer OpenSSH szuka autoryzowanych kluczy w katalogu określonym w konfiguracji serwera za pomocą opcji AuthorizedKeysFile. Domyślnie .ssh/authorized_keys znajduje się w katalogu domowym użytkownika.

Jednakże, przechowywanie autoryzowanych kluczy w katalogu domowym użytkownika oznacza, że użytkownik może dodawać nowe klucze autoryzujące logowanie do jego konta. Jest to wygodne, ale użytkownik może następnie przekazać te klucze przyjaciołom lub kolegom, a nawet sprzedać je za Bitcoiny (tak się rzeczywiście stało). Klucze SSH są ponadto trwałe i zachowują ważność do czasu ich usunięcia.

Jeśli autoryzowane klucze są dodawane dla kont root lub kont serwisowych, łatwo zachowują ważność nawet po opuszczeniu organizacji przez osobę, która je zainstalowała. Są one również wygodnym sposobem dla hakerów do ustanowienia stałej obecności w systemie, jeśli nie ma wykrywania i alarmowania o nieautoryzowanych nowych kluczach.

Z tych powodów większość większych organizacji chce przenieść autoryzowane klucze do lokalizacji należącej do roota i ustanowić dla nich kontrolowany proces dostarczania i zakończenia.

Przenoszenie kluczy SSH do lokalizacji root-owned

Zasadniczo przenoszenie kluczy SSH do lokalizacji root-owned jest proste:

Utwórz odpowiedni katalog root-owned, np, /etc/ssh/keys, w którym przechowywane są autoryzowane klucze.
Utwórz podkatalog w tym katalogu dla każdego użytkownika i przenieś plik authorized_keys każdego użytkownika do /etc/ssh/keys/<user>/authorized_keys.
Na koniec zmień zestaw AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys w /etc/ssh/sshd_config.

W praktyce jednak nie zawsze jest to takie proste, zwłaszcza w większych środowiskach. Nazwy użytkowników mogą pochodzić z katalogów (np. Active Directory lub LDAP). Wiele organizacji posiada różne wersje OpenSSH, w tym bardzo stare systemy lub niestandardowe kompilacje SSH, które posiadają niestandardowe wbudowane ścieżki. Zalecamy użycie narzędzi do zarządzania kluczami, takich jak Universal SSH Key Manager, aby ukryć tę złożoność w większych środowiskach. Narzędzia te mogą również implementować dostarczanie, usuwanie i zatwierdzanie kluczy oraz alarmować o nieautoryzowanych zmianach dokonanych przez użytkowników root.

Ograniczenie liczby kluczy prywatnych przez OpenSSH

Serwer OpenSSH posiada cechę (nazwałbym to błędem), która zalicza testowanie czy dany klucz może być użyty do uwierzytelnienia jako próbę uwierzytelnienia. Ma to taką konsekwencję, że jeśli użytkownik ma więcej niż pięć kluczy w .ssh, tylko niektóre z nich działają. To często powoduje, że uwierzytelnianie oparte na kluczach kończy się niepowodzeniem i jest często trudne do rozgryzienia przez użytkowników. Sposobem na obejście tego problemu jest jawne określenie klucza prywatnego do użycia za pomocą opcji -i. Alternatywą jest dostosowanie sesji MaxAuthTries na serwerze, ale nie jest to pełne rozwiązanie i niepożądane jest zwiększenie liczby prób uwierzytelnienia hasłem.

Jak wyglądają klucze SSH

Klucz autoryzowany może wyglądać tak:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

Klucz tożsamości może wyglądać tak:

Jak działa uwierzytelnianie w SSH?

Inicjalizacja połączenia w SSH składa się z:

Negocjacji wersji protokołu do użycia
Negocjacji algorytmów kryptograficznych i innych opcji do użycia
Negocjacji jednorazowego klucza sesji do szyfrowania
Negocjacji klucza sesji do szyfrowania
Negocjacji klucza sesji doczasowego klucza sesji do szyfrowania reszty sesji
Uwierzytelnianie hosta serwera przy użyciu jego klucza hosta
Uwierzytelnianie użytkownika przy użyciu hasła, uwierzytelniania kluczem publicznym lub w inny sposób.

Po tym można wymieniać dane, w tym dane terminala, grafikę i pliki.

Klucz SSH - Uwierzytelnianie przy użyciu kluczy SSH

Uwierzytelnianie przy użyciu klucza publicznego

Mechanizm uwierzytelniania oparty na kluczach w SSH nazywany jest uwierzytelnianiem przy użyciu klucza publicznego. Zasadniczo, niektóre dane specyficzne dla sesji są podpisywane przy użyciu prywatnego klucza tożsamości. Podpis jest następnie wysyłany do serwera, który sprawdza, czy klucz użyty do podpisu jest skonfigurowany jako klucz autoryzowany. Serwer następnie weryfikuje podpis cyfrowy używając klucza publicznego w kluczu autoryzowanym. Klucz identyfikacyjny nigdy nie jest wysyłany do serwera.

Niezbędną rzeczą w uwierzytelnianiu kluczem publicznym jest to, że pozwala on jednemu serwerowi na dostęp do innego serwera bez konieczności wpisywania hasła. Ta potężna cecha sprawia, że jest ono tak szeroko stosowane do przesyłania plików (przy użyciu protokołu SFTP) i zarządzania konfiguracją. Jest również powszechnie wykorzystywany przez administratorów systemów do jednokrotnego logowania.

Jak powszechne są klucze SSH i jakie jest ryzyko

Klucze SSH okazują się być niezwykle powszechne i szeroko stosowane. Wiele dużych organizacji gromadziło je przez dwadzieścia lat bez żadnej kontroli. Typowe przedsiębiorstwo z listy Fortune 500 posiada kilka milionów kluczy umożliwiających dostęp do swoich serwerów. W przypadku jednego z klientów, zbadaliśmy 500 aplikacji i 15 000 serwerów, i znaleźliśmy 3 000 000 autoryzowanych kluczy i 750 000 unikalnych par kluczy. Organizacja ta posiadała również ponad pięć milionów codziennych logowań przy użyciu kluczy. Klucze te były wykorzystywane do przeprowadzania transakcji finansowych, aktualizacji konfiguracji, przenoszenia danych dziennika, transferu plików, interaktywnego logowania przez administratorów systemu i wielu innych celów.

Okazuje się, że większość dużych przedsiębiorstw posiada setki tysięcy, a nawet miliony kluczy. Te klucze to dostęp, który jest nierozliczany i może stanowić zagrożenie dla całego przedsiębiorstwa.

Jak całkowicie wyeliminować klucze SSH

PrivX On-Demand Access Manager może być użyty do całkowitego wyeliminowania kluczy SSH z serwerów i ustanowienia opartej na polityce kontroli dostępu i logowania sesji w całym przedsiębiorstwie. Eliminuje również większość obciążeń administracyjnych związanych z zarządzaniem kluczami, zapewniając jednocześnie korzyści: automatyzację i pojedyncze logowanie.