Jak Kerberos działa z SSH?

22

Załóżmy, że mam cztery komputery: Laptop, Server1, Server2, serwer Kerberos:

  • Loguję się przy użyciu PuTTY lub SSH z L do S1, podając moją nazwę użytkownika / hasło
  • Z S1 I następnie SSH do S2. Hasło nie jest potrzebne, ponieważ Kerberos mnie uwierzytelnia

Opisz wszystkie ważne wymiany protokołów SSH i KRB5: „L wysyła nazwę użytkownika do S1”, „K wysyła ... do S1” itp.

(To pytanie ma być zredagowane przez społeczność; popraw je dla czytelników nie będących ekspertami ).

Phil
źródło

Odpowiedzi:

27

Pierwsze logowanie:

  • L wysyła nazwę użytkownika i żądanie uwierzytelnienia SSH do S1
  • S1 zwraca dostępne mechanizmy uwierzytelniania SSH, z „hasłem” jako jednym z nich
  • L wybiera „hasło” i wysyła proste hasło do S1
  • S1 podaje nazwę użytkownika i hasło do stosu PAM.
  • Na S1 PAM (zwykle pam_krb5lub pam_sss) żąda biletu TGT (bilet przyznający bilet) od KDC Kerberos.
    1. S1 uzyskuje TGT.
      • Stary styl (bez preauth): S1 wysyła AS-REQ i odbiera AS-REP zawierający TGT.
      • Nowy styl (z preauth): S1 używa hasła do szyfrowania aktualnego znacznika czasu i dołącza go do AS-REQ. Serwer odszyfrowuje znacznik czasu i sprawdza, czy mieści się w dozwolonym przesunięciu czasu; jeśli deszyfrowanie się nie powiedzie, hasło jest natychmiast odrzucane. W przeciwnym razie TGT jest zwracany w AS-REP.
    2. S1 próbuje odszyfrować TGT za pomocą klucza wygenerowanego z Twojego hasła. Jeśli deszyfrowanie się powiedzie, hasło zostanie zaakceptowane jako prawidłowe.
    3. TGT jest zapisywany w nowo utworzonej pamięci podręcznej poświadczeń. (Możesz sprawdzić $KRB5CCNAMEzmienną środowiskową, aby znaleźć pamięć podręczną, lub użyć, klistaby wyświetlić jej zawartość).
  • S1 używa PAM do sprawdzania autoryzacji (zależnie od konfiguracji) i otwarcia sesji.
    • Jeśli pam_krb5zostanie wywołany na etapie autoryzacji, sprawdza, czy ~/.k5loginistnieje. Jeśli tak, musi podać nazwę klienta Kerberos. W przeciwnym razie jedynym dozwolonym zleceniodawcą jest .username@DEFAULT-REALM

Drugie logowanie:

  • S1 wysyła nazwę użytkownika i żądanie uwierzytelnienia SSH do S2
  • S2 zwraca dostępne mechanizmy uwierzytelniania, jednym z nich jest „gssapi-with-mic” 1
  • S1 żąda biletu , wysyłając TGS-REQ z TGT do KDC i otrzymując TGS-REP z biletem serwisowym od niego.host/s2.example.com@EXAMPLE.COM
  • S1 generuje „AP-REQ” (żądanie uwierzytelnienia) i wysyła je do S2.
  • S2 próbuje odszyfrować żądanie. Jeśli się powiedzie, uwierzytelnianie zostanie wykonane. (PAM nie jest używany do uwierzytelniania).
    • Inne protokoły, takie jak LDAP, mogą wybrać szyfrowanie dalszej transmisji danych za pomocą „klucza sesji”, który został dołączony do żądania; jednak SSH wynegocjowało już własną warstwę szyfrowania.
  • Jeśli uwierzytelnianie się powiedzie, S2 używa PAM do sprawdzenia autoryzacji i otwarcia sesji, tak samo jak S1.
  • Jeśli przekazywanie poświadczeń było włączone, a TGT ma flagę „przekazywalną”, wówczas S1 żąda kopii TGT użytkownika (z ustawioną flagą „przekazywaną”) i wysyła ją do S2, gdzie zostaje zapisana w nowej pamięci podręcznej. Umożliwia to rekurencyjne logowanie z uwierzytelnieniem Kerberos.

Pamiętaj, że możesz także uzyskać TGT lokalnie. W systemie Linux możesz to zrobić za pomocą kinit, a następnie połączyć za pomocą ssh -K. W przypadku systemu Windows, jeśli jesteś zalogowany w domenie Windows AD, system Windows zrobi to za Ciebie; w przeciwnym razie można użyć MIT Kerberos . PuTTY 0.61 obsługuje zarówno Windows (SSPI), jak i MIT (GSSAPI), chociaż musisz ręcznie włączyć przekazywanie (delegowanie).


1 gssapi-keyex jest również możliwe, ale nie został przyjęty do oficjalnego OpenSSH.

grawitacja
źródło
Czy mógłbyś rozwinąć relację między hasłem, TGT i odpowiedzią KDC? Nie jest jasne, w jaki sposób PAM decyduje, czy hasło jest prawidłowe.
Phil
UWAGA: To zdanie jest niepoprawne: „S1 wysyła TGS-REQ i odbiera TGS-REP zawierający TGT”. Niepoprawnie, ponieważ TGT są częścią AS_REP. Sprzedaż biletów wróci z TGS_REPn
jouell
1
Najnowsze wersje OpenSSH mają wymianę kluczy. Myślę, że 4.2p1 była pierwszą wersją z łatkami. ( sxw.org.uk/computing/patches/openssh.html )
quinnr
Nie, nie robią tego. Są to łatki innych firm . To właśnie miałem na myśli przez „nie przyjęto do oficjalnego OpenSSH”
grawity
0

Krótko mówiąc: najlepiej, bilety Kerberos należy uzyskać na terminalu (L), albo za pomocą kinitpolecenia, albo jako część lokalnej sekwencji logowania w tak zwanej konfiguracji „pojedynczego logowania”. Systemy zdalne (S1, S2) byłyby wówczas dostępne bez monitowania o podanie hasła. Dostęp łańcuchowy (L → S1 → S2) byłby możliwy dzięki zastosowaniu techniki znanej jako „przekazywanie biletów”. Taka konfiguracja wymaga w szczególności bezpośredniego dostępu do KDC z terminala (L).

Inna odpowiedź grawitacji szczegółowo wyjaśnia to podejście.

szarpać
źródło
-2

Jedynym nieoczywistym krokiem tutaj jest to, że na S1 jest moduł PAM, który użył twoich poświadczeń do wykonania kiniti dostaje ci bilet przyznający bilet z K (uwierzytelnienie klienta). Następnie, gdy łączysz SSH z S2 przy użyciu uwierzytelniania Kerberos, odbywa się uwierzytelnianie usługi klienta. Nie widzę korzyści z przejścia przez tę żmudną wymianę wiadomości po wiadomości.

Rzuć a -vvvna swoje polecenie ssh, jeśli chcesz zobaczyć każdą wiadomość i przeczytać opis Wikipedii Kerberos.

themel
źródło
2
Odpowiedź na pytanie, które wymaga szczegółów, brzmi: „Nie widzę korzyści z rozwijania szczegółów” wydaje mi się dość niegrzeczna.
Massimo