Scentralizowany system zarządzania kluczami SSH?

27

Chcemy przejść na zarządzanie loginami SSH oparte na kluczach i zastanawiamy się, czy istnieją systemy zarządzania kluczami, które pozwoliłyby nam centralnie zarządzać kluczami dostępu na całym świecie.

System powinien idealnie zezwalać na wydawanie kluczy na klienta i ich odwoływanie w razie potrzeby, aktualizowanie kluczy serwera na bieżąco.

Czy ktoś wie o takim systemie, komercyjnym lub open source?

UWAGA: Aby to wyjaśnić, potrzebujemy zarządzania kluczami dla dość dużej liczby serwerów w chmurze (podobnych do EC2) i niewielkiej liczby użytkowników usług. Myślę, że łatka LDAP + sugeruje, że może być dobrym rozwiązaniem.

ssh cloud keys

— SyRenity
źródło

7

Czy tylko ja uważam, że „klucze prywatne i chmura” są jak „pij i jedź”. Obie bawią się osobno, ale nigdy nie idą w parze.

— mailq

1

„Chmura” to prawdopodobnie niewłaściwe słowo - brzmi to tak, jakby chcieli scentralizowanego uwierzytelniania o ogólnoświatowej spójności.

— voretaq7

Cześć. Dokładnie - tego właśnie szukamy.

— SyRenity,

Walczę z tym problemem z niektórymi środowiskami hybrydowymi moich klientów. Pozostaje również pytanie, gdzie przechowywać OPenLDAP lub instancję centralną w chmurze? Używam webmina wszystkich rzeczy jako narzędzia do zarządzania kluczami i książki kucharskiej szefa kuchni do synchronizacji kluczy z węzłami.

— Tom H

Userify obejmuje to, czego szukasz (patrz serverfault.com/questions/647797/… )

— Jamieson Becker,

8

Jest na to wiele sposobów. Pamięć kluczy LDAP została wspomniana kilka razy, a ja to zrobiłem i działa, o ile to możliwe. LDAP ma jednak swoje własne ciekawostki związane z zarządzaniem, które wymagają trochę nauki.

Jestem wielkim fanem prostych, solidnych serwerów, które mają minimalne zależności od sieci zewnętrznej w przypadku prostych rzeczy, takich jak uwierzytelnianie administratorów, więc skłaniam się ku zdecydowanie bardziej niezawodnej strategii dystrybucji kluczy SSH - mam to do czynienia z systemem zarządzania konfiguracją. Klucz publiczny każdego użytkownika jest przechowywany w systemie zarządzania konfiguracją i wszędzie tam, gdzie osoba musi się zalogować, jego klucz jest dodawany. System konfiguracji wie także o usuwaniu kluczy, które nie zostały określone, więc kiedy ktoś odchodzi lub zmienia się jego klucz, wystarczy usunąć konfigurację klucza, a przy następnym uruchomieniu systemu konfiguracji klucz jest usuwany.

— womble
źródło

Takie podejście jest z pewnością dobre i, jak zauważa Womble, ma tę zaletę, że serwery pozostają uruchomione (i dostępne) w przypadku awarii LDAP - każdy system oparty na LDAP powinien (ośmielę się powiedzieć, że musi ) mieć przynajmniej jeden użytkownik, którego klucze zostały wypchnięte w sposób opisany przez Womble. Minusem jest to, że musisz przeprowadzić konfigurację, aby cofnąć autoryzację użytkowników. Nie ma problemu z „kontem awaryjnym” z tylko kilkoma autoryzowanymi użytkownikami. Większy problem dla dużej liczby kont :)

— voretaq7

1

Tak czy inaczej, naprawdę musisz mieć sposób na uruchomienie masowej konfiguracji, więc nie powinno być problemu z zmianą konta.

— womble

Zgadzam się, niestety potrzeby biznesowe / mentalność nie: Paranoja w wielu miejscach (w tym moja) dyktuje, że zmiany konfiguracji odbywają się poza godzinami pracy, ale nowy personel / pracownicy odchodzący mogą zdarzyć się w dowolnym momencie: - /

— voretaq7

1

Więc z przyjemnością zostawiasz zepsute rzeczy na dzień roboczy tylko dlatego, że nie możesz uruchomić wypychania konfiguracji w ciągu dnia? To, że jest powszechne, nie znaczy, że nie jest głupie.

— womble

2

Cześć. Więc dobrym pomysłem byłoby na przykład użycie Puppet?

— SyRenity,

23

Użytkownik powinien wygenerować pary kluczy.

Użytkownik zachowuje prywatną połowę - nigdy nie powinieneś jej widzieć. Jeśli posiadasz czyjś klucz prywatny w formie, w której możesz go odczytać / użyć, źle robisz bezpieczeństwo.

Część publiczna jest udostępniana (za pomocą dowolnego mechanizmu: formularza internetowego, wiadomości e-mail, opcji „daj mi to na płycie CD”), która ma być scentralizowana w dowolny sposób. Niektóre miejsca przechowują klucze publiczne w LDAP. Inni wypychają authorized_keyspliki za pomocą systemu wdrażania.

W moim środowisku użytkownicy, którzy potrzebują dostępu do powłoki, dają mi swoje klucze publiczne. Te klucze są dodawane do naszego systemu LDAP i sshdkonsultują się z kluczami publicznymi wymienionymi dla każdego użytkownika w celu ich uwierzytelnienia, za pomocą łatki klucza publicznego LDAP .
Gdy ktoś musi dodać dodatkowy klucz lub odwołać istniejący klucz, informuje administratora, a my się nim zajmujemy. W końcu, kiedy skalujemy, wdrożę system, który pozwala ludziom obracać swoimi kluczami publicznymi.

Każda z naszych witryn ma parę serwerów LDAP, zsynchronizowanych z naszym serwerem głównym za pomocą replikacji LDAP, dzięki czemu dane są spójne (i dostępne) w każdej lokalizacji.

Wszystko, co opisałem, można zrobić za pomocą oprogramowania typu open source. Istnieją również produkty komercyjne, które robią to samo.
Musisz dokładniej zbadać dostępne opcje i zdecydować, które najlepiej pasują do Twojego środowiska. Jeśli masz dalsze (bardziej szczegółowe) pytania, prawdopodobnie możemy być bardziej pomocni.

— voretaq7
źródło

Zasadniczo sugerujesz korzystanie z infrastruktury LDAP, z poprawionym OpenSSH, który będzie działał z LDAP? Jak dobrze to się skaluje w produkcji? Czy może obsługiwać dużą liczbę maszyn? Musimy obsługiwać tylko niewielką liczbę użytkowników usług.

— SyRenity,

1

@SyRenity: LDAP obsługuje replikację i klastrowanie, dzięki czemu skaluje się bardzo dobrze

— Hubert Kario

@SyRenity Teoretycznie możesz obsługiwać nieograniczoną liczbę komputerów w nieograniczonej liczbie lokalizacji (pomyśl „Naprawdę duże wdrożenie usługi Active Directory” - AD to w zasadzie LDAP z modnymi akcesoriami). Użytkownikom usług sugeruję ujednolicenie ich w całym środowisku i wypchnięcie znormalizowanych plików /etc/passwdoraz /etc/groupplików (pozwala na normalne działanie maszyn i uruchamianie / uruchamianie powiązanych usług, nawet jeśli LDAP nie jest dostępny)

— voretaq7

@ voretaq7 Czyli użytkownicy usługi będą zarządzani niezależnie od LDAP, poprzez zarządzanie konfiguracją?

— SyRenity

@SyRenity tak - i co ważniejsze dostępne dla usług, które z nich korzystają, jeśli LDAP nie działa . Zaplanuj awarie, w przeciwnym razie wystąpią katastrofy.

— voretaq7

9

Klucze nie powinny być generowane nigdzie, ale na komputerze każdego użytkownika. Klucze prywatne są nazywane jako takie z jakiegoś powodu.

To powiedziawszy, mogłem zobaczyć przypadek użycia dla pewnego rodzaju scentralizowanego repozytorium kluczy publicznych użytkowników. Jedną z opcji byłoby przechowywanie kluczy publicznych w OpenLDAP - najnowsze wersje OpenSSH mogą odczytywać klucze z LDAP.

— EEAA
źródło

2

Czy klucz publiczny LDAP jest teraz w głównej linii OpenSSH? Znam tylko łatkę LPK (za którą mogę ręczyć - działa świetnie). Również +1 za utrzymanie prywatnych kluczy prywatnych.

— voretaq7

@ voretaq7 Chyba słyszałem, że włącza się do głównej linii, ale sam tego jeszcze nie zweryfikowałem. Udostępniamy wspólne katalogi domowe za pośrednictwem NFS, dzięki czemu dba o nas nasza kluczowa dystrybucja.

— EEAA,

+1 dobrze, nie wiedziałem tego. zaoszczędziłoby mi to wielu kłopotów. to teraz na mojej liście rzeczy do obejrzenia.

— Tom H

1

Wiem, że jest to nieco starsze pytanie, ale Google zwraca je dość wysoko, gdy szuka tego rodzaju rzeczy.

Dla tych z nas, którzy szukają rozwiązania oprócz LDAP, właśnie znalazłem projekt „SKM”: https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
źródło

1

Istnieje wiele świetnych komercyjnych i otwartych rozwiązań, takich jak Userify [1] (tam, gdzie pracuję), Universal Key Manager [2], SSH Key Box [3] itp. Zależy to od twoich potrzeb i tego, czy jesteś szukając czegoś, co scentralizuje zarządzanie podczas decentralizacji operacji (aby twoje serwery nie polegały na centralnym organie do zalogowania się ... w takim przypadku możesz nie być w stanie zalogować się na żaden z serwerów, jeśli, powiedzmy, twój Serwer LDAP nie działa!)

Zobacz także tę dyskusję Slant:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Jamieson Becker
źródło