SSH: Czy używasz jednej pary kluczy prywatny / publiczny dla każdego komputera zdalnego? Czy pojedyncza para dla wszystkich?


23

Jeśli chcesz mieć loginy ssh oparte na kluczu publicznym dla wielu komputerów, czy używasz jednego klucza prywatnego i umieszczasz ten sam klucz publiczny na wszystkich komputerach? A może masz jedną parę kluczy prywatny / publiczny dla każdego połączenia?


@Jim Zajkowski: Nie jestem pewien, jak odpowiedzieć na twój komentarz, ale to jest dla ciebie. Skocznie umożliwiają kontrolowany dostęp do serwerów internetowych znajdujących się w strefie DMZ (za zaporą ogniową). Załóżmy, że masz „server_a” i „server_b”. A jest w sieci, a B jest poza siecią. Klienci zewnętrzni łączą się z B. Ruch, który przechodzi z punktu A do punktu B, musi być kontrolowany i odwrotnie. Więc dodajesz pole skoku, które ma dwie karty sieciowe. Jeden, który łączy go z siecią wewnętrzną (A) i ten, który łączy go z siecią zewnętrzną (B). Więc od A idziesz do pola skoku, a następnie do B. Jedną z korzyści

@IMTheNachoMan - Przekształciłem twoją odpowiedź na komentarz, chociaż najlepszym miejscem na to byłby komentarz znajdujący się bezpośrednio w odpowiedzi zawierającej komentarz, na który odpowiadasz (co wywołało u mnie zawroty głowy). Jeśli masz jakieś pytania, przejdź do meta i zapytaj. Dzięki za wyjaśnienie, niezależnie od tego.
Kara Marfia

Odpowiedzi:


27

Używam jednego klucza na zestaw systemów, które mają wspólną granicę administracyjną. Ogranicza to liczbę komputerów, które wyskakują w przypadku naruszenia klucza, ale nie całkowicie przytłacza moją zdolność do przechowywania i zarządzania kilkoma tysiącami kluczy. Różne hasła na każdym kluczu oznaczają, że nawet jeśli wszystkie klucze prywatne zostaną skradzione, a jeden klucz zostanie naruszony, reszta nie pójdzie z nim do toalety. Ponadto, jeśli zrobisz coś głupiego (na przykład skopiujesz klucz prywatny na niezaufany komputer), znowu nie musisz ponownie wszystkiego wszystkiego, tylko maszyny powiązane z tym kluczem.


4

Klucz publiczny nie ma większego znaczenia, ponieważ z definicji można go opublikować. Tak więc jedynym problemem jest prywatność twoich kluczy prywatnych. Są na twojej maszynie i wszystkie razem, więc jeśli ktoś zostanie narażony na szwank, prawdopodobne jest, że wszyscy zostaną zagrożeni. Dlatego wiele par kluczy to po prostu więcej pracy dla tego samego efektu.

Używam różnych kluczy tylko dla różnych kont lub ról, które z definicji nie powinny mieć pełnego nakładania się.


2

Jeśli dobrze rozumiem, każdy serwer będzie miał swój własny klucz publiczny.

Dla danego użytkownika możesz wygenerować jeden klucz i używać go wszędzie, o ile klucz prywatny jest replikowany na wszystkich hostach inicjujących. (Odbywałoby się to automatycznie za pośrednictwem montowanych w sieci katalogów domowych i opartego na katalogu systemu uwierzytelniania, takiego jak OpenLDAP, ponieważ użytkownik zawsze będzie „taki sam”, niezależnie od tego, z której stacji roboczej się loguje.)

Poza systemem użytkownika opartym na katalogach myślę, że używanie tego samego klucza wszędzie jest kiepskim pomysłem - kończy się to obniżeniem poziomu bezpieczeństwa systemu, ponieważ każdy, kto może uzyskać klucz z dowolnej stacji roboczej, może następnie uwierzytelnić się jako tego użytkownika na zdalnym serwerze.

Inną alternatywą, narzuconą przez kilka dużych korporacji (i jestem pewien, że również małe) jest to, aby nigdy nie pozwolić „użytkownikowi” na używanie kluczy współdzielonych, ale raczej zalogować się w polu „skoku” lub „centrum” , suodpowiedniemu łączącemu się użytkownikowi, a następnie SSH stamtąd do serwerów, którymi muszą zarządzać.

Ponadto, jeśli korzystasz z systemu zarządzania, takiego jak platforma HP Server Automation, to zdalne administrowanie zarządzanymi serwerami staje się bardziej uproszczonym procesem.


1
Wszyscy powinni mieć zaszyfrowane klucze. Czy potrafisz wyjaśnić zalety bezpieczeństwa „skoczka”, ponieważ go nie widzę.
Jim Zajkowski

jak zaimplementowano w kilku bankach, z którymi miałem do czynienia, a gdzie indziej idea „skoczka” polega na tym, że nie możesz uzyskać dostępu do serwerów w strefie DMZ lub podsieci itp. z „normalnym” użytkownikiem. Łączysz się z polem skoku, a następnie w zalogowanej formie, su do użytkownika zarządzającego, aby połączyć się z inną siecią.
warren

2
Korzyści bezpieczeństwa == 0, innymi słowy.
womble

@womble - być może to prawda. Ale to właśnie robi wiele paranoicznych firm. Ponieważ susesja jest rejestrowana, można ją kontrolować.
warren

1
dlaczego tylko susesje są kontrolowane, a nie pozostałe?
João Portela

1

Jak powiedzieli inni, chociaż koncepcja wielu par kluczy może wydawać się bardziej bezpieczna, jeśli istnieje szansa, że ​​zostaną one użyte w taki sposób, że wszystkie znajdują się w tym samym miejscu, jest to po prostu bardziej kłopotliwe i nie bardziej bezpieczne. Wiele haseł uczyniłoby to bezpieczniejszym, ale także duży ból głowy, próbując zapamiętać, które hasło pasuje do którego klucza, a który klucz do którego serwera.

Najbardziej rozsądną odpowiedzią byłaby dla mnie ta, w której zasugerowano, aby zrobić to TYLKO, jeśli obejmuje ona oddzielne role administracyjne bez nakładania się. Tak, że mogą to być różni ludzie zajmujący się różnymi rolami lub na różnych stacjach roboczych lub cokolwiek innego. W takim przypadku masz do czynienia z bardziej wyjątkowymi rzeczami dla każdej roli, więc jest to bardziej uzasadnione.


0

Aby ułatwić zarządzanie wieloma serwerami obsługującymi SSH, możesz wypróbować cssh . Możesz łączyć cssh z kluczami SSH z podanymi hasłami, aby znacznie zwiększyć swoją zdolność do zarządzania wieloma serwerami jednocześnie.


2
Jak udaje ci się zdobyć „szalone błędy” w chwalebnej pętli for?
womble

Coś w tym wydaje się bardzo zabójcze ... Jeśli popełnisz błąd, spieprzysz wszystkie serwery na raz zamiast jednego!
Nick

@Nick - prawda, ale prawie zawsze tak jest, gdy jestem odpowiedzialny za pudło =) @womble - co? do jakich „zwariowanych błędów” mówisz?
Greeblesnort

1
Na górze strony projektu, do której linkujesz: „UWAGA: Wkrótce wrócę do tego projektu, aby naprawić w nim szalone błędy”. Fakt, że zawiadomienie jest nadal dostępne dwa lata później, nie zwiększa mojej wiary w to.
womble
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.