Jak Kerberos działa z SSH?

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 ).

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” ¹
• 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).

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

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.

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.