W folderze projektu nadal leży stary klucz administratora. Działa na kilku serwerach, ale nikt nie wie dokładnie, kto ma jego kopię. Przejście z haseł na klucze SSH zmieniło wtedy sposób logowania, lecz nie wyjaśniło odpowiedzialności.
Skuteczne zarządzanie SSH łączy indywidualne tożsamości, właściwe uprawnienia na systemach docelowych i niezawodne odebranie dostępu. Zależnie od środowiska mogą wystarczyć utrzymywane klucze publiczne z rzetelną ewidencją. Większe lub często zmieniające się środowiska mogą skorzystać z krótkoterminowych certyfikatów SSH. Obie drogi wymagają możliwego do utrzymania procesu.
Cztery rzeczy, których nie należy mylić
Prywatny klucz użytkownika pozwala potwierdzić własną tożsamość. Jest przechowywany bezpiecznie i nie jest rozsyłany przez czat, e-mail ani niezabezpieczony folder projektu. Odpowiadający mu klucz publiczny może zostać zapisany na wskazanych systemach docelowych w celu autoryzacji dostępu. Jego odcisk ułatwia jednoznaczne przypisanie w ewidencji.
Klucz hosta identyfikuje natomiast serwer, z którym nawiązywane jest połączenie. Weryfikacja hosta zapobiega niezauważonemu połączeniu z niewłaściwą stroną. Certyfikat SSH uzupełnia klucz publiczny o podpisane informacje, na przykład o tożsamości i ważności. Certyfikaty OpenSSH mają własny format i nie są zwykłymi certyfikatami TLS/X.509.
Oddzielić logowanie osobiste od zadań technicznych
Prace administracyjne przypisuje się osobom i ich dozwolonym zadaniom. Wspólny, długoterminowy klucz root niepotrzebnie utrudnia odejścia, rotację i rozliczalność. Lepszą podstawą są indywidualne logowania z odpowiednio uregulowanymi prawami administratora.
Zadanie kopii zapasowej lub wdrożenia potrzebuje własnej tożsamości technicznej z udokumentowaną odpowiedzialnością. Gdy to możliwe, dostęp ogranicza się do konkretnej funkcji, na przykład przez wymuszone polecenie i właściwe reguły przekazywania. Prywatny klucz pracownika nie powinien niepostrzeżenie stać się trwałym warunkiem działania automatycznego zadania.
Od ewidencji kluczy do krótkoterminowych certyfikatów
Przy niewielkiej liczbie systemów może wystarczyć kontrolowana dystrybucja kluczy publicznych. Ewidencja obejmuje osobę lub usługę, odcisk, systemy docelowe, zakres i planowany termin przeglądu lub wymiany. Kluczowe jest niezawodne utrzymywanie uprawnień na wszystkich objętych systemach.
Urząd certyfikacji SSH może zamiast tego podpisywać klucze publiczne na ograniczony czas i dla określonych tożsamości. Serwery ufają wskazanemu CA i sprawdzają pozostałe reguły. Prywatnego klucza logowania nie trzeba przekazywać CA. Klucze CA i zasady wydawania są chronione szczególnie starannie.
Krótka ważność zmniejsza okres używania wydanego poświadczenia. Nie kończy jednak aktywnej sesji i nie zastępuje procesu odebrania dostępu. Po odejściu osoby należy także uniemożliwić wydawanie nowych certyfikatów. Centralna platforma zarządzania sekretami jest jednym z modeli działania; musi rzeczywiście obsługiwać konkretny proces SSH.
| Sposób zarządzania | Odpowiednie zastosowanie | Wymagania utrzymania |
|---|---|---|
| Utrzymywanie kluczy publicznych | Niewielki, dobrze zinwentaryzowany zbiór systemów docelowych. | Dystrybucja, usuwanie starych uprawnień i zastępstwa. |
| Wydawanie certyfikatów SSH | Ograniczona ważność i określone tożsamości. | Ochrona CA, zasady wydawania, zaufanie serwerów i odwołanie. |
| Tożsamości techniczne | Automatyzacja z jasno określonym zadaniem. | Ograniczone prawa na celach, odpowiedzialność i procedura rotacji. |
| Agent lub klucz sprzętowy | Odpowiednie metody osobistego uwierzytelniania. | Ograniczenia przekazywania, kontrola wersji i odzyskiwanie dostępu. |
Świadomie korzystać z agenta i kluczy sprzętowych
Agent SSH umożliwia logowanie przy użyciu załadowanych kluczy bez kopiowania pliku klucza prywatnego na każdy serwer. Przekazanie agenta udostępnia jednak systemowi zdalnemu jego funkcje podpisywania. OpenSSH wyraźnie ostrzega, że atakujący z odpowiednim dostępem do tego systemu może uwierzytelniać się za pomocą załadowanych tożsamości bez odczytania samych kluczy.
Przekazywanie agenta włącza się zatem wyłącznie dla potrzebnej ścieżki. Obsługiwane ograniczenia czasowe lub docelowe mogą wyznaczyć dodatkowe granice. Sprzętowe klucze bezpieczeństwa to kolejna możliwość odpowiedniego dostępu interaktywnego. Klient, serwer, typ klucza i wymogi dotyku lub PIN muszą być zgodne; zadanie bezobsługowe ma inne potrzeby niż osobiste logowanie.
Rotacja i odwołanie muszą dotrzeć do systemu docelowego
Wymiana klucza w notebooku nie usuwa starego dostępu z serwera. Przy zapisanych kluczach publicznych trzeba zaktualizować uprawnienia na wszystkich objętych systemach. Dla certyfikatów można dodatkowo przewidzieć mechanizmy takie jak OpenSSH Key Revocation Lists. Unieważnienie działa dopiero wtedy, gdy wskazane serwery poprawnie je stosują.
Procedura obejmuje także utracone urządzenie, skompromitowany klucz i niedostępną usługę zarządzania. Niezależny dostęp awaryjny jest chroniony, dokumentowany i kontrolowanie testowany. Odzyskanie dostępu nie może zależeć właśnie od ścieżki, która uległa awarii.
Różnicować postępowanie w środowiskach Linux i Proxmox
W środowiskach mieszanych rejestruje się wersje i faktycznie obsługiwane funkcje OpenSSH. Aktualna instrukcja nie gwarantuje, że każda instalacja Linuksa ma te same opcje. Nowe reguły wdraża się z wyznaczonym dostępem testowym i sprawdzoną drogą powrotu.
Proxmox VE wykorzystuje SSH również do własnych funkcji klastra, w tym określonych połączeń konsolowych, migracji i replikacji. Te techniczne relacje zaufania ocenia się osobno od osobistych dostępów administratorów. Ogólne czyszczenie lub nadpisywanie plików kluczy może zakłócić pracę. Zmiany weryfikuje się więc według dokumentacji zainstalowanej wersji.
Co obejmuje rozsądny pierwszy krok
DAXS ewidencjonuje istniejące dostępy SSH, przypisuje odpowiedzialność i planuje właściwy sposób zarządzania. Pilotaż testuje logowanie, uprawnienia, odebranie dostępu, rejestrowanie i odzyskiwanie. Samo udane logowanie nie wystarcza jako kryterium odbioru. Same logi logowania również nie są automatycznie pełnym zapisem wszystkich wykonanych poleceń.
Usługi infrastrukturalne oraz artykuł o Proxmoxie w firmie przedstawiają kontekst utrzymania. Dla wspólnych portali perspektywę uzupełnia artykuł o sejfach, rolach i odejściach pracowników . Można zlecić inwentaryzację dostępów administracyjnych.
Częste pytania
Czy mogę przekazać klucz publiczny?
Część publiczna służy do odpowiedniej dystrybucji. Nadal trzeba sprawdzić przypisanie do właściwej osoby i systemu. Część prywatna jest chroniona i nie krąży jako wspólny plik dostępowy.
Czy krótkoterminowy certyfikat wystarcza do natychmiastowego odebrania dostępu?
Nie. Trzeba łącznie uwzględnić wydawanie, pozostałą ważność, sprawdzanie unieważnienia i aktywne sesje. Krótki okres nie zastępuje tego procesu.
Czy centralny urząd certyfikacji jest zawsze potrzebny?
Nie. Odpowiednie rozwiązanie zależy od skali, częstotliwości zmian, automatyzacji i możliwości utrzymania. Staranna obsługa kluczy może wystarczyć dla niewielkiego zbioru systemów.
Źródła: OpenSSH: logowanie i autoryzowane klucze (link zewnętrzny) · OpenSSH: certyfikaty i listy unieważnień (link zewnętrzny) · OpenSSH: reguły zaufania i unieważniania na serwerze (link zewnętrzny) · OpenSSH: przekazywanie agenta (link zewnętrzny) · OpenSSH: klucze agenta i ograniczenia (link zewnętrzny) · Proxmox VE: podręcznik administratora, SSH w klastrze (link zewnętrzny)
Ujęcie koncepcyjne; konkretne funkcje zależą od zainstalowanych wersji i planowanej obsługi.
