Pracujesz z dużą ilością serwerów linuxowych podczas swojej pracy?
Do każdego z nich logujesz się przy pomocy swojego klucza SSH?
Z jednej strony chciałbyś go często zmieniać, ale z drugiej natłok pracy związany ze zmianą certyfikatów na wielu serwerach Cię przytłacza?
Popatrzmy na rozwiązanie stosowane w firmie Netflix1.
W standardowej konfiguracji serwera SSH, jeżeli chcemy aby nasz klucz pozwalał na logowanie się do serwera musimy dodać go do pliku ~/.ssh/authorized_keys.
Wtedy serwer wie, że osoba posługująca się danym kluczem jest uprawniona do dostępu do danego serwera.
Wszystko działa fajnie, o ile łączymy się z jednym serwerem i jesteśmy jego jedynym administratorem.
Sprawa się komplikuje jeżeli serwerów do nadzorowania jest kilkanaście oraz jeśli nie jesteśmy jedynymi ich administratorami.
Klucz każdego administratora, który posiada dostęp do danego komputera musi się bowiem znaleźć w wyżej wymienionym pliku.
Dodatkowo w przypadku wycieku któregokolwiek z kluczy - musimy go usunąć ze wszystkich serwerów aby chronić ich bezpieczeństwo.
Jak zatem można poradzić sobie z tym problemem?
W serwerze SSH możemy skonfigurować opcję nazwaną TrustedUserCAKeys2.
Co nam daje takie rozwiązanie i jak ono działa?
Ta opcja sprawia że serwer nie sprawdza konkretnego klucza.
Sprawdza natomiast czy podany klucz został podpisany przez inny klucz - ten, który podajemy w konfiguracji TrustedUserCAKeys.
Można to porównać do zaufania certyfikatów SSL.
Na świecie istnieją podmioty, których klucz jest traktowany przez przeglądarki jako zaufany.
Kiedy chcemy aby nasza strona była dostępna poprzez link https, generujemy swój własny kluczy prywatny i publiczny i prosimy, aby instytucja traktowana przez przeglądarki jako zaufana podpisała nasz klucz publiczny swoim kluczem prywatnym.
Firma sprawdza zatem czy jesteśmy właścicielami danej domeny i jeżeli wszystko się zgadza podpisuje nasz klucz swoim kluczem.
Podczas przeglądania Internetu przeglądarka aby wyświetlić zieloną kłódkę przy naszym adresie sprawdza zatem czy nasz klucz jest podpisany kluczem firmy, której ufa.
W ten sposób przeglądarka wie, że może ufać danemu certyfikatowi.
Ten sam schemat jest wykorzystywany tutaj.
Za każdym razem gdy chcemy połączyć się z serwerem nie używamy naszego klucza SSH, ale generujemy kompletnie nowy, unikalny klucz.
Następnie łączymy się z serwerem certyfikacji, który posiada w swoich zasobach klucz prywatny, rozpoznawany przez wszystkie nasze serwery jako zaufany.
Serwer ten sprawdza czy posiadamy prawa do logowania do danego serwera i podpisuje nasz klucz swoim kluczem prywatnym.
Tak podpisany klucz mógłby być używany cały czas.
Dlatego stosuje się dodatkowy parametr, który określa dokładny okres czasu w którym można użyć danego klucza.
Dzięki temu będzie się nim można zalogować tylko przez określony czas.
W tej sytuacji - nawet jeśli nasz klucz wycieknie - nie będzie on już ważny dla serwera.
Jeżeli jakiejś osobie odbieramy prawa do danego serwera - wystarczy odpowiednio zmodyfikować uprawnienia w serwerze podpisującym - tak aby nie podpisywał on dla danego użytkownika kluczy.
Bless to narzędzie które służy właśnie do takiego celu.
Zostało stworzone w taki sposób aby można go było w prosty sposób uruchomić na serwerach firmy Amazon.
Stawiamy więc instancję tego serwera razem z naszym kluczem prywatnym w infrastrukturze AWS Lambda.
Teraz, jeżeli chcemy połączyć się z jakimś serwerem najpierw używamy serwera Bless.
Logujemy się do niego przy pomocy naszych danych do Amazona.
Co ciekawe, można to skonfigurować w taki sposób, aby oprócz loginu hasła wymagane było dwuskładnikowe uwierzytelnienie.
Jeżeli potrzebujesz implementacji klienta w Pythonie - warto popatrzeć na projekt pokrewny3.
Icon made by Freepik, Flat-icons-com, srip,
Flat Icons, monkik, Smashicons, Prosymbols
from www.flaticon.com
