jaki jest cel ssh-agent?


70

Przeczytałem oficjalną definicję:

ssh-agent to program do przechowywania kluczy prywatnych używanych do uwierzytelniania klucza publicznego (RSA, DSA, ECDSA). Chodzi o to, że ssh-agent jest uruchamiany na początku sesji X lub sesji logowania, a wszystkie inne okna lub programy są uruchamiane jako klienci programu ssh-agent. Dzięki zastosowaniu zmiennych środowiskowych agent może zostać zlokalizowany i automatycznie użyty do uwierzytelnienia podczas logowania do innych komputerów za pomocą ssh (1).

„.. program do przechowywania kluczy prywatnych.” - IMHO - klucze ssh są generowane przez użytkownika za pomocą polecenia ssh-keygen i po prostu przechowywane w ~ / .ssh - dlaczego potrzebuję demona do przechowywania tych kluczy? Jak to dokładnie je trzyma - czy nie są one po prostu przechowywane w .ssh?

„są uruchamiane jako klienci programu ssh-agent” - nie rozumiem. Gdzie by to było potrzebne? Zwykle używam ssh w następujący sposób:

 ssh -i ~/.ssh/private_key_name username@hostname

Co dokładnie oznacza „klient” - co to za klienci? Czy nie uruchamiasz po prostu komendy ssh z terminala, aby się połączyć - jacy są inni klienci i dlaczego nie mogą po prostu użyć ścieżki do tego prywatnego pliku ssh, tak jak komenda ssh?

Odpowiedzi:


75

Agent SSH obsługuje podpisywanie danych uwierzytelniających. Podczas uwierzytelniania na serwerze musisz podpisać niektóre dane za pomocą klucza prywatnego, aby udowodnić, że jesteś sobą.

Ze względów bezpieczeństwa większość osób rozsądnie chroni swoje klucze prywatne za pomocą hasła, więc każda próba uwierzytelnienia wymagałaby wprowadzenia tego hasła. Może to być niepożądane, więc ssh-agent buforuje klucz dla ciebie i musisz wprowadzić hasło tylko raz, gdy agent chce go odszyfrować (a często nawet nie tak, ponieważ ssh-agent można zintegrować z pam, co robi wiele dystrybucji).

Agent SSH nigdy nie przekazuje tych kluczy programom klienckim, a jedynie przedstawia gniazdo, na którym klienci mogą wysyłać dane i na które odpowiada podpisanymi danymi. Zaletą tego jest to, że możesz używać swojego klucza prywatnego nawet w programach, którym nie w pełni ufasz.

Inną zaletą agenta SSH jest to, że można go przekazywać przez SSH. Tak więc, gdy ssh do hosta A, podczas przesyłania dalej agenta, możesz następnie ssh z A do innego hosta B bez potrzeby posiadania klucza (nawet w formie zaszyfrowanej) na hoście A.


10
Wydaje mi się, że jest to najbardziej kompletna odpowiedź, ale wciąż brakuje jednej kwestii. Użycie klucza agenta pozwala również na łatwe użycie wielu kluczy. Zamiast określać ścieżkę do klucza, podczas korzystania z agenta klucza ssh wypróbuje każdy klucz w nim.
Patrick,

3
@Patrick, co może być również wadą - wypróbuj zbyt wiele nieprawidłowych kluczy na serwerze, a połączenie zostanie zamknięte, zanim dojdziesz do ważnego klucza. Oczywiście, to co ~/.ssh/config„s IdentityFileopcja jest dobra do, z lub bez środka
Tobias Kienzler

@Patrick, który wydaje się równie możliwy bez agenta
Andrey Fedorov

@AndreyFedorov Tak, możesz mieć wiele kluczy bez agenta, ale możesz także określić w swoim ~/.ssh/configkluczu, który klucz ma być używany dla zdalnego hosta, aby wiedział dokładnie, którego potrzebuje.
Patrick

3
więc można założyć, że ssh-agentnie jest to konieczne, jeśli klucz prywatny nie jest chroniony hasłem?
pkaramol

16

Zaletą ssh-agentjest to, że hasło należy wpisać tylko raz. Jeśli twój prywatny klucz RSA nie jest szyfrowany za pomocą hasła, ssh-agent nie jest konieczny. sshKomenda będzie przykładem klienta.


7

Jeśli rutynowo wchodzisz sshna wiele różnych komputerów, każdy z własnym kluczem i hasłem, wówczas uruchomienie ssh-agentpozwala wprowadzić hasło dla każdego klucza raz 1 na początku sesji, a następnie możesz uwierzytelnić się na każdym komputerze tyle razy, ile razy jak chcesz, bez konieczności ponownego wprowadzania hasła.

Kolejną korzyścią jest to, że zgodnie ze manstroną agent nigdy nie wysyła klucza prywatnego przez kanał żądania; więc jeśli przeskakujesz między różnymi skrzynkami, twoje klucze prywatne są chronione.

1 Możesz ustawić lifeczas przechowywania kluczy w agencie.


6

Artykuł w Wikipedii ma prawdopodobnie najlepszy opis:

Weryfikacja na serwerze opiera się na uwierzytelnianiu typu wyzwanie-odpowiedź. ssh łączy się z serwerem za pomocą nazwy użytkownika i żądania klucza. Demon ssh otrzymuje żądanie i odsyła wyzwanie na podstawie klucza publicznego zapisanego w pliku uwierzytelniającym. ssh używa klucza prywatnego do skonstruowania odpowiedzi klucza i wysyła go do oczekującego sshd na drugim końcu połączenia. Nie wysyła samego klucza prywatnego. Demon ssh sprawdza odpowiedź klucza, a jeśli jest poprawny, zapewnia dostęp do systemu. ssh-agent upraszcza to, tworząc gniazdo nasłuchujące połączeń SSH. Użytkownik po prostu uruchamia ssh-agent, mówiąc mu, jak znaleźć swoje klucze (jeśli nie znajdują się w domyślnej lokalizacji), wprowadza hasło dla każdego klucza, który ma być używany, jednorazowo,

Znowu dosłownie z artykułu w Wikipedii:

... ssh-agent tworzy gniazdo, a następnie sprawdza połączenia z ssh. Każdy, kto może połączyć się z tym gniazdem, ma również dostęp do agenta ssh. Uprawnienia są ustawione jak w zwykłym systemie Linux lub Unix. Po uruchomieniu agent tworzy nowy katalog w / tmp z ograniczonymi uprawnieniami. Gniazdo znajduje się w folderze.

Zazwyczaj jest umieszczany w plikach rc systemu lub użytkownika, takich jak $HOME/.bashrclub $HOME/.profile(dla powłok bash), aby ssh-agentzestaw zmiennych środowiskowych został całkowicie włączony do środowiska.

W moim systemie Fedora 14 uruchamia się dość wcześnie jako część podsystemu X11. W tym pliku /etc/X11/xinit/xinitrc-common:

# Prefix launch of session with ssh-agent if available and not already running.
SSH_AGENT=
if [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
  fi
fi

Zmienna $SSH_AGENTjest następnie wykorzystywana w innych skryptach startowych X11, takich jak tutaj /etc/X11/xinit/Xclients:

exec -l $SHELL -c "$SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"

Po włączeniu go tutaj, następujące zmienne środowiskowe są ustawiane jako część powłoki nadrzędnej, dlatego też wszystkie dzieci pod rozwidleniem powinny je mieć, na przykład:

SSH_AUTH_SOCK=/tmp/ssh-PspRF18958/agent.18958; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18959; export SSH_AGENT_PID;

Jest w tym trochę więcej złożoności, ale w skrócie to w zasadzie o to chodzi ssh-agent.

Na przykład w GNOME ssh-agentjest uruchamiany na użytkownika jako aplikacja startowa:

                     ss aplikacji startowych

TL; DR

Podsumowując, ssh-agentistnieje tak, że gdy twoje klucze ssh są wymagane, musisz je odblokować tylko raz za pomocą hasła (zakładając, że je mają), a następnie są dostępne w formie odszyfrowanej w pamięci (RAM).


1

„są uruchamiane jako klienci programu ssh-agent” odnosi się do idei, że ssh-agent jest uruchamiany podczas (lokalnej) inicjacji sesji logowania, aby wszystkie programy otrzymały zmienne środowiskowe $SSH_AGENT_PIDi $SSH_AUTH_SOCKktóre są niezbędne do podłączenia agenta.

Kolejną zaletą wykluczenia obsługi klucza prywatnego z ssh jest to, że ssh-agent można zastąpić gpg-agent. Dzięki temu możesz używać kluczy OpenPGP (z możliwością uwierzytelniania) dla SSH. To dobre rozwiązanie dla kluczy OpenPGP na karcie inteligentnej.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.