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

42

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?

slacy
źródło

Odpowiedzi:

33

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.

dwc
źródło
4
Nie rozumiem sensu opcji 4. Nie ma to żadnego sensu.
niXar
26

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.

Jeremy Bouse
źródło
Wow, świetne rozwiązanie, dzięki! Uwielbiam uniwersalną konfigurację w ~ / .ssh / config
slacy
Udowodniono, że bardzo wygodnie jest rozdzielić rzeczy do pracy, na osobiste i konsultacyjne serwery sieciowe klientów ... Nie chcę mieszać uwierzytelniania między nimi, ale chcę też, żeby było dla mnie łatwe.
Jeremy Bouse
Niesamowity! Naprawdę kocham ten.
balu
Zakładam, że używasz różnych kluczy USB dla różnych komputerów klienckich. W przeciwnym razie jaki jest sens oddzielnych kluczy, jeśli wszystkie są przechowywane w tym samym miejscu? W przypadku naruszenia zasad należy cofnąć je wszystkie. Chyba, że ​​(i prawdopodobnie) czegoś mi brakuje, wydaje się, że to komplikuje sprawy.
Halil Özgür,
@ HalilÖzgür, Tak, konsultuję się i nie zawsze chcę używać tego samego klucza. Ponieważ klucz USB jest zaszyfrowany i nie jest podłączony do żadnego komputera, chyba że potrzebuję go do nawiązania połączenia, nie ma obaw o naruszenie serwera, a hasło do odszyfrowania systemu plików dysku jest wystarczająco długie, aby odwołanie kluczy było wystarczająco proste.
Jeremy Bouse
6

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).

David Z
źródło
Tak, zmieniono nazwę na odpowiednią „Opcję 2”. Podoba mi się zasada „nigdy nie kopiuj klucza prywatnego”. To dobra zasada.
slacy
1

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

diq
źródło
Tak, to jest to. Koniecznie sprawdź niektóre z przykładów na stronie. Pomaga zobaczyć, co zrobili już inni - nie trzeba wymyślać koła na nowo.
diq
1

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.

pgs
źródło