System dystrybucji kluczy publicznych SSH

26

Mamy wiele różnych systemów zarządzanych przez kilka osób. Zdecydowaliśmy się na uwierzytelnianie za pomocą klucza publicznego SSH, aby uzyskać dostęp do tych systemów. Działa to świetnie, ponieważ nie trzeba zarządzać hasłami do kont administracyjnych ani dzielić się nimi, nie trzeba zapamiętywać haseł do różnych systemów (tylko hasło do klucza prywatnego), nie ma potrzeby interakcji (wprowadzania hasła) z każdym zdalnym poleceniem .

Problem polega na tym, że kluczami publicznymi zainstalowanymi w systemach trzeba jakoś zarządzać. Ludzie przychodzą i odchodzą, klucze mogą zostać naruszone, obowiązki się zmienią (osoba upoważniona do wejścia do jednego systemu dzisiaj może być upoważniona do dostępu do innego jutro). Obecnie zarządzamy nim, ręcznie edytując pliki ~ / .ssh / Author_keys na każdym koncie, które tego potrzebuje, ale jest to dużo pracy i podatne na błędy.

Czy istnieje gotowe narzędzie do zarządzania kluczami publicznymi w takim scenariuszu? Czy masz własne rozwiązania? A może cała idea zarządzania systemami w ten sposób jest wadliwa?

ssh ssh-keys public-key Jacek Konieczny
źródło
Naprawdę nie potrafię odpowiedzieć na twoje pytanie, ale kiedy je przeczytałem, mogłem po prostu usłyszeć, jak krzyczy o jakiś system baz danych.
John Gardeniers
Rzeczywiście widzę miejsce dla bazy danych na „backend” („serwerze kluczy”), chociaż wolałbym tam ograniczyć dostęp do bazy danych i rozdzielić klucze na kanał SSH. Nie otwierać żadnych innych kanałów komunikacji w systemach zarządzanych. Tak naprawdę czuję, że jestem w stanie samodzielnie wdrożyć takie narzędzie / system, choć wolałbym coś gotowego i sprawdzonego.
Jacek Konieczny

Odpowiedzi:

18

Jak już wspomniano przez pulegium każdy generic oprogramowanie do zarządzania konfiguracją jak Lalek , Chef , Bcfg2 lub cfengine mógł wykonać zadanie.

Ponieważ plik autoryzowanych_kluczy nie jest tak skomplikowany, do zarządzania tym plikiem możesz także użyć programu rsync lub (D) SCM, takiego jak git lub hg . Masz plik „master” na jednym ze swoich serwerów i podajesz go przez rsync / git / hg /…. Na każdym innym serwerze uruchamiasz zadanie cron, które okresowo pobiera kopię główną (jeśli została zmieniona) i kopiuje ją do właściwej lokalizacji lokalnej. Cholera, działałoby to nawet z czystym HTTP lub FTP.

Najważniejsze jest to: posiadaj jedną „główną” kopię pliku autoryzowanych_kluczy i zaktualizuj go. Pozwól „klientom” (komputerom, które powinny mieć bieżący plik kluczy autoryzowanych) pobrać go z serwera głównego i wdrożyć lokalnie.

joschi
źródło
1
Z łatwością używamy marionetki do zarządzania ~ 200 serwerami Linux (klucze pub są tylko plikiem, który można wymusić jako atrybut użytkownika).
ForgeMan
1
Przyjmę tę odpowiedź, ponieważ wydaje się, że nie poprawię się. Wydaje mi się, że mam do wyboru następujące opcje: 1. Zachowaj rzeczy takimi, jakie są teraz 2. Zbuduj własny łańcuch narzędzi do zarządzania plikami autoryzowanych kluczy 3. Użyj istniejącego, ogólnego narzędzia do zarządzania serwerami, takimi jak Puppet lub Chef… chociaż te narzędzia wydają się zbyt duże, aby to proste zadanie. 4. Użyj innego mechanizmu uwierzytelniania / autoryzacji (takiego jak Kerberos)… chociaż wydaje się to również zbyt skomplikowanym narzędziem do prostego zadania Dzięki.
Jacek Konieczny
ten system jest tak bezpieczny, jak kanał, przez który jest pobierana kopia główna.
yrk
1
Ansible to bardzo lekki system CM, który ma moduł do zmutowania z autoryzowanymi plikami kluczy przez ssh. Zobacz ansible.cc/docs/modules.html#authorized-key
RS
11

Dostępna jest łatka dla OpenSSH, która pozwala na korzystanie z kluczy publicznych z serwera LDAP, ale ma to sens tylko wtedy, gdy sprawdzanie konta / autoryzacji konta odbywa się również na tym serwerze LDAP (tak konfiguruje się moje środowisko). Jest również tak bezpieczny, jak konfiguracja LDAP (więc chcesz używać SSL i kluczy weryfikacyjnych).

Zobacz http://code.google.com/p/openssh-lpk/, aby uzyskać informacje o łatce i dodatkowe szczegóły. Domyślnie nie znam żadnego systemu operacyjnego dostarczanego z tą łatką, ale jeśli korzystasz z FreeBSD, jest to opcjonalna łatka, jeśli używasz OpenSSH z portów.

voretaq7
źródło
1
Nawiasem mówiąc, użycie pam_ldap pozwala również rozwiązać problem „ktoś upoważniony do dostępu do maszyny A dzisiaj może nie mieć uprawnień do uzyskania dostępu do niej jutro” - przeczytaj na pam_ldap, jeśli jesteś zainteresowany tym aspektem ...
voretaq7
5

uruchamiam bardzo proste rozwiązanie, które robi to samo z regułami zapory ogniowej

przykładowy plik hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribute.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

to cała magia :-)

bmaeser
źródło
5

Obecnie sprawdzam SSH KeyDB . Ma to robić dokładnie to, administrować rolami, serwerami i użytkownikami, dystrybuować klucze użytkowników, zbierać klucze hostów itp. Ma nawet coś, co nazywa się „lokalizacjami”.

Jeszcze tego nie wypracowałem i nie jestem pewien, czy to w pełni działa. Kod jest jednak w Pythonie i wydaje się być dość łatwy w zarządzaniu, więc nie powinno być zbyt trudno go odkurzyć i uruchomić.

andsens
źródło
1

Nie jestem pewien, co rozumiesz przez wielu, ani nie wiem, czy chcesz się zmienić, ale Kerberos to droid, którego szukasz. To elegancko rozwiąże twoje problemy i uwierzytelni zarówno ludzi, jak i maszyny.

pboin
źródło
1

Masz dwa (zwykle zmieniające się w 3) różne problemy, które próbujesz rozwiązać:

  • Uwierzytelnianie (kim jesteś?)
  • Autoryzacja (Czy masz dostęp do tego serwera?)
  • Audyt (co zrobiłeś?)

Autoryzacja za pomocą klucza publicznego jest czasem dobrym sposobem na uwierzytelnienie, ale w ogóle nie dotyczy autoryzacji. Nie podoba mi się uwierzytelnianie za pomocą klucza publicznego, ponieważ bardzo łatwo jest pójść na kompromis (szczególnie wewnętrznie), chyba że masz jakieś dobre kontrole.

Właśnie tutaj wchodzą takie rozwiązania jak Kerberos. W świecie Windows usługa Active Directory rozwiązuje ten problem. W świecie uniksowym istnieje mnóstwo wyborów, co jest zarówno dobre, jak i złe.

Sprawdziłbym projekt Red Hat FreeIPA , który jest pakietem oprogramowania, który ułatwia szybkie uruchomienie i uruchomienie podobnego do AD systemu Kerberos / LDAP / DNS.

duffbeer703
źródło
Rozumiem różnicę między uwierzytelnianiem, autoryzacją i audytem. A „klucze autoryzowane” SSH zapewniają zarówno dane uwierzytelniające, jak i autoryzacyjne. Nie jest doskonały, ale jest prosty. A prostota jest często dużą zaletą, również w zakresie bezpieczeństwa. Kerberos ze swoją skomplikowaną infrastrukturą może zawieść pod wieloma względami pod względem bezpieczeństwa niż ssh z plikami autoryzowanych_kluczy. Chociaż nie oznacza to, że jedno lub drugie jest bezpieczniejsze.
Jacek Konieczny
Zarządzanie plikami kluczy autoryzowanych dotyczy np. Kilku serwerów, ale szybko osiągasz punkt, w którym zarządzanie nim jest niemożliwe. Nie próbowałem powiedzieć, że to „złe” rozwiązanie. Podobnie złożoność Kerberos jest nieodpowiednia dla dwóch serwerów ... ale inwestycja w projektowanie / wdrażanie Kerberos jest tego warta w większym środowisku.
duffbeer703
1

Możesz używać Bcfg2 z kontami bcfg2 do dystrybucji authorized_keys. Jako dodatkowy bonus będziesz mieć możliwość kontrolowania użytkowników i grup.

Bcfg2 umożliwia również bezbolesną konserwację za /etc/ssh/ssh_known_hostspomocą SSHbase .

myroslav
źródło
1

Istnieje również SKM

andsens
źródło