Keychain w Gentoo

1.  Podstawy

Przedstawienie problemu

Jeśli wszystkie komputery działają pod kontrolą Gentoo i każdy z nich ma uruchomionego demona SSH, to trochę kłopotliwe wydaje się bieganie między nimi i podawanie na każdym hasła. Możliwe, że posiadamy jakiś skrypt albo, że ustawiliśmy zadanie w cronie, które ładnie łączy się przez SSH. Jest też inne rozwiązanie tego problemu, polegające na uwierzytelnianiu za pomocą kluczy publicznych.

Jak działa uwierzytelnianie za pomocą kluczy publicznych?

Załóżmy, że mamy klienta próbującego połączyć się z serwerem. Klient generuje parę kluczy i wysyła jeden z nich (klucz publiczny) serwerowi. Następnie serwer odsyła wezwanie zaszyfrowane za pomocą owego klucza publicznego klientowi, który próbuje sie połączyć. Jedynie posiadacz prywatnego klucza (klient) jest w stanie odszyfrować wezwanie, poprawna odpowiedź prowadzi do udanego uwierzytelnienia.

2.  W jaki sposób używać uwierzytelniania za pomocą klucza publicznego?

Generowanie pary kluczy

Pierwszym krokiem jest wygenerowanie pary kluczy, wykorzystamy do tego komendę ssh-keygen:

$ ssh-keygen -t dsa
(Należy zaakceptować domyślne wartości i podać długie hasło)

Nowo utworzony klucz prywatny będzie znajdował się w pliku ~/.ssh/id_dsa, a publiczny w ~/.ssh/id_dsa.pub. Teraz jesteśmy gotowi skopiować klucz publiczny na serwer.

Operacje na serwerze

Skopiujemy nasz plik ~/.ssh/id_dsa.pub na serwer, na którym działa sshd i tam dodamy go do pliku ~/.ssh/authorized_keys zawierającego użytkowników łączących się z serwerem. Oto mały przykład jak to zrobić (należy mieć dostęp do tego serwera poprzez ssh!).

$ scp ~/.ssh/id_dsa.pub uzytkownik_serwera@serwer:~/moj_komputer.pub
$ ssh uzytkownik_serwera@serwer "cat ~/moj_komputer.pub >> ~/.ssh/authorized_keys"
$ ssh uzytkownik_serwera@serwer "cat ~/.ssh/authorized_keys"

Ostatnie polecenie umieści klucz w pliku ~/.ssh/authorized_keys. Należy się upewnić, że wpis jest prawidłowy.

Testowanie ustawień

Teoretycznie, jeżeli wszystko poszło jak należy, a serwerowy demon SSH pozwoli na to, łączenie z serwerem powinno odbywać się już bez podawania hasła. Nadal będziemy musieli odszyfrowywać klucz prywatny z hasłem, ale nie powinno się to mieszać z hasłem użytkownika na serwerze.

$ ssh uzytkownik_serwera@serwer

Powinno pojawić się zapytanie o hasło do klucza id_dsa, po którego podaniu zostaniemy zalogowani na serwer (o ile hasło zostanie podane prawidłowo). Jeżeli tak się nie stanie należy zalogować się na konto użytkownik_serwera@serwer i jeszcze raz sprawdzić poprawność danych w ~/.ssh/authorized_keys (warto upewnić się, że każdy wpis znajduje się w osobnej linii). Warto też zerknąć czy demon SSH może dokonywać uwierzytelniania za pomocą kluczy publicznych.

Wiele osób w tym momencie myśli: "Bez sensu, po prostu jedno hasło zostało zastąpione drugim". Spokojnie, dalsza część tekstu pokazuje kolejny sposób na zaoszczędzenie cennego czasu.

3.  Upraszczanie autoryzacji za pomocą kluczy publicznych

Typowe zarządzanie kluczami za pomocą ssh-agent

Na pewno fajnie by było raz odszyfrować klucz(e) i uzyskać swobodny dostęp do wszystkich kont, bez żadnych haseł... No i da się to zrobić! Właśnie do tego służy program ssh-agent.

Program ssh-agent zwykle uruchamia się wraz z sesją serwera X albo podczas wywołania skryptu powłoki, takiego jak ~/.bash_profile. ssh-agent tworzy gniazdo UNIX-owe oraz rejestruje kilka zmiennych środowiskowych tak, że wszystkie późniejsze aplikacje mogą korzystać z tej usługi łącząc się z gniazdem. Dlatego sensowne jest jego uruchamianie jako nadrzędnego procesu dla sesji X-ów jeżeli chcemy pominąć deszyfrowanie kluczy publicznych podczas uruchamiania programów z graficznym GUI.

$ ssh-agent

Podczas uruchamiania ssh-agent pojawi się informacja o jego numerze PID. Ponadto ssh-agent ustawia takie zmienne środowiskowe jak SSH_AUTH_SOCK i SSH_AGENT_PID. Jeżeli plik ~/.ssh/id_dsa jeszcze nie istnieje, zostanie on utworzony podczas pierwszego uruchomienia; pojawi się prośba o hasło. Jeśli posiadamy inne klucze prywatne możemy je dodać do działającego ssh-agenta za pomocą polecenia ssh-add, tak, jak pokazano poniżej:

$ ssh-add jakis_klucz

Czary-mary. Od tej pory na podstawie klucza można dostać się na każdy z serwerów bez podawania hasła.

$ ssh serwer

Bardzo cenna może okazać się informacja o tym jak zabić ssh-agent w razie jakiejś nagłej konieczności, prawda?

$ ssh-agent -k

Można jeszcze bardziej uprościć korzystanie z ssh-agent, opowiemy o tym w następnym akapicie. Przed przejściem do niego należy jednak jeszcze raz się upewnić, że ssh-agent jest uruchomiony i działa prawidłowo.

Ostatni poziom uproszczenia obsługi ssh-agent

Keychain pozwala wielokrotnie używać ssh-agent pomiędzy logowaniami. Opcjonalnie może prosić o hasło podczas każdego poszczególnego logowania. Zanim jednak przejdziemy dalej, musimy go zainstalować.

# emerge keychain

Możemy już uruchomić keychaina, zakładając, że wszystko poszło pomyślnie. Poniższą linijkę dodajemy do ~/.bash_profile by go uruchomić:

keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh

Sprawdźmy jak to działa. Na początku upewniamy się, że ssh-agent opisany w poprzedniej sekcji na pewno jest wyłączony, potem logujemy się do nowej powłoki lub po prostu włączamy nowy terminal. Powinno pojawić się zapytanie o hasło do każdego klucza określonego w linii komend. Powłoki uruchomione po tej będą używać ssh-agent'a, pozwalając ci nawiązywać połączenia bez podawania haseł SSH.

Keychain w KDE

Jeżeli korzystamy z KDE, możemy zamiast ~/.bash_profile, wykorzystać je do gospodarowania naszym ssh-agent. Jeżeli zdecydujemy się na to, będziemy musieli wyedytować plik /usr/kde/${KDE_VERSION}/env/agent-startup.sh, który jest wczytywany przy starcie KDE oraz plik /usr/kde/${KDE_VERSION}/shutdown/agent-shutdown.sh, który wykonywany jest podczas wyłączania KDE, gdzie ${KDE_VERSION} jest dwoma pierwszymi członami naszej wersji KDE. Jeżeli mamy na przykład wersję 3.5.1 powyższe pliki powiniśmy wyedytować tak:

if [-x /usr/bin/ssh-agent]; then
  eval "$(/usr/bin/ssh-agent -s)"
fi

if [-n"${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Następnym krokiem jest uruchomienie ulubionego terminala (np. Konsole) i załadowanie potrzebnych kluczy. Np.:

keychain ~/.ssh/id_dsa
(Tutaj wpisujemy hasło do klucza)

Klucze zostaną zapamiętane dopóki nie zakończymy sesji KDE lub nie zabijemy ręcznie ssh-agent.

4.  Podsumowujące uwagi

Wątek bezpieczeństwa

Oczywiście użycie ssh-agent niesie ze sobą pewne niebezpieczeństwo. Przypadkowy użytkownik może zalogować się do wszystkich serwerów za pomocą powłoki, podczas gdy właściciel konta np. jest w łazience. Niesie to również pewne niebezpieczeństwo dla serwerów z którymi się łączymy, więc należy zachować podstawowe reguły bezpieczeństwa. Jeśli już decydujemy się tak znacznie osłabić bezpieczeństwo serwerów warto uważnie pilnować bezpieczeństwa każdej z sesji ssh-agent.

Rozwiązywanie problemów

Czynności opisane w tym dokumencie nie należą do skomplikowanych i nie powinny przysparzać problemów. Jeśli jednak wystąpią jakieś błędy warto:

• Jeśli nie można nawiązać połączenia bez ssh-agent należy połączyć sie przez SSH z opcją -vvv by znaleźć problem. Niektóre serwery są tak skonfigurowane, że nie mogą używać kluczy publicznych, a inne zawsze muszą pytać o lokalne hasło dostępu! W tym wypadku można użyć opcji SSH wraz z parametrem -o lub zmienić ustawienia serwerowego demona SSH.
• Kłopoty związane z ssh-agent i keychainem mogą też wynikać z tego, że używana jest powłoka, która nie rozumie poleceń jakie one wywołują. Więcej informacji na ten temat współpracy z innymi powłokami można znaleźć w manualach ssh-agent i keychain.

Zawartość tego dokumentu jest rozpowszechniana na podstawie licencji Creative Commons - Attribution / Share Alike.