Najlepszy system do zarządzania kluczami ssh? [Zamknięte]

Mam kilka komputerów klienckich (tj. Laptopy, komputery stacjonarne itp.) I łączę się z kilkoma urządzeniami serwerów, którymi zarządzam, i loguję się na nich przez SSH. Mogę sobie wyobrazić kilka schematów zarządzania kluczami ssh, które miałyby sens, i jestem ciekawy, co robią inni.

Opcja 1: Jeden globalny klucz publiczny / prywatny.

Wygenerowałbym jeden klucz publiczny / prywatny i umieściłem klucz prywatny na każdej maszynie klienta oraz klucz publiczny na każdej maszynie serwera.

Opcja 2: Jedna para kluczy na maszynę serwerową.

Wygenerowałbym jedną parę kluczy na każdym komputerze serwera i umieściłbym każdy klucz prywatny na moich komputerach klienckich.

Opcja 3: Jedna para kluczy na maszynę klienta.

Każdy komputer kliencki miałby unikalny klucz prywatny, a każdy komputer serwera miałby klucze publiczne dla każdego komputera klienckiego, z którym chciałbym się połączyć.

Opcja 4: Jedna para kluczy na parę klient / serwer

Całkowicie za burtę?

Który z nich jest najlepszy? Czy są inne opcje? Jakie kryteria zastosować przy ocenie właściwej konfiguracji?

Korzystam z Opcji 3: Jedna para kluczy na maszynę kliencką i jest to dla mnie najbardziej sensowne. Oto niektóre z powodów:

• W przypadku naruszenia bezpieczeństwa klienta klucz (i tylko ten klucz) należy usunąć z serwerów.
• Jest wystarczająco elastyczny, aby decydować, do czego mogę uzyskać dostęp, bez udzielania ogólnego dostępu do wszystkich serwerów od wszystkich klientów.
• Bardzo wygodne Jest tylko 1 klucz do ssh-add, bez zamieszania.
• Łatwy w konfiguracji i zarządzaniu w ramach Opcji 4

Opcja 4 jest fajna, ale to po prostu zbyt dużo pracy. Opcja 3 zapewnia ci 98% i znacznie mniej problemów.

Korzystam z rozwiązania, które jest nieco bardziej skomplikowane, ale bardzo wszechstronne, ponieważ chcę zachować pewną separację w kluczach tożsamości SSH używanych dla moich domowych serwerów sieciowych, serwerów biurowych, serwerów sieciowych klientów konsultingowych i innych różnych systemów, na których mam konta.

Teraz powiedziałem, że pracuję ze stacji roboczych Linux prawie wyłącznie, więc mam klucz USB, który jest konfigurowany przy użyciu szyfrowania LUKS, a mój menedżer okien X11 wraz z demonem HAL wykrywają zaszyfrowany dysk LUKS i pytają o hasło deszyfrowania po włożeniu i próbują być zamontowanym. Przechowując to na zaszyfrowanym dysku tak, jak ja, nigdy nie przechowuję moich kluczy SSH na żadnej stacji roboczej.

Mam wtedy następującą konfigurację w moim ~/.ssh/configpliku:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

% D przekłada się na katalog domowy użytkownika przez OpenSSH oraz w ~ / .ssh katalogu Stworzyłem keys.d jako linku do ścieżki katalogu na zaszyfrowanym dysku USB, gdy jest prawidłowo zamontowany.

Wyrażenie % l jest tłumaczone na nazwę hosta lokalnych komputerów klienckich, a % u zostanie przetłumaczone na nazwę użytkownika klienta lokalnego.

Ta konfiguracja umożliwia SSH wyszukiwanie klucza przy użyciu 3 różnych wyrażeń. Na przykład, jeśli nazwa użytkownika jdoemojego klienta lokalnego to i nazwa mojego komputera klienta lokalnego examplehost, wyglądałoby to w następującej kolejności, dopóki nie znajdzie klucza, który istniał i został zaakceptowany przez serwer zdalny.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Możesz nawet użyć wyrażenia % r, aby wyszukać klucz specyficzny dla nazwy użytkownika zdalnego serwera lub % h dla nazwy hosta zdalnego serwera, tak jak użyto % u i % l .

Aktualizacja: Teraz właściwie korzystam z gnu-agent GnuPG ze zgodnością ssh-agent, aby po prostu odczytać i użyć klucza uwierzytelniającego z mojej karty inteligentnej OpenPGP v2.

Wyeliminowałbym obie twoje opcje 1 (z których, jak podejrzewam, jedna miała być opcją 2 ;-), ponieważ klucze prywatne to poufne dane i sensowne jest trzymanie ich w jak najmniejszej liczbie miejsc. Osobiście nigdy nie kopiowałbym klucza prywatnego z jednego komputera na inny (lub nawet z jednego pliku do drugiego na tym samym komputerze), z wyjątkiem może tworzenia kopii zapasowych. Chociaż w przeciwieństwie do większości kluczy szyfrujących, zgubienie klucza SSH to nie koniec świata (po prostu utwórz nowy, nie stracisz żadnych danych).

Opcja 3 i użyj czegoś takiego jak Puppet do obsługi zarządzania kluczami.

Opcja 3.

Pozwala to również kontrolować, do których serwerów klient może uzyskać dostęp. np. jeśli klient X potrzebuje dostępu do serwerów A i B, ale C lub D, skopiujesz jego klucz publiczny tylko do tych hostów.