Як Керберос працює з SSH?

Припустимо, у мене є чотири комп'ютери: ноутбук, сервер1, сервер2, сервер Kerberos:

• Я входжу за допомогою PuTTY або SSH від L до S1, даючи своє ім’я користувача / пароль
• Від S1 я потім SSH до S2. Не потрібно вводити пароль, оскільки Kerberos підтверджує мене

Опишіть усі важливі протоколи обміну протоколами SSH та KRB5: "L надсилає ім'я користувача S1", "K відправляє ... до S1" тощо.

(Це питання має бути відредаговане спільнотою; вдосконаліть його для неекспертного читача .)

Перший логін:

• L надсилає запит на автентифікацію імені користувача та SSH на S1
• S1 повертає наявні механізми аутентифікації SSH, з "паролем" як одним із них
• L вибирає "пароль" і відправляє звичайний пароль на S1
• S1 дає ім'я користувача та пароль для стека PAM.
• На S1 PAM (як правило, pam_krb5або pam_sss) запитує TGT (квиток на отримання квитка) від КДК Керберос.
  1. S1 отримує TGT.
     • Старий стиль (без преаути): S1 надсилає AS-REQ і отримує AS-REP, що містить TGT.
     • Новий стиль (з preauth): S1 використовує ваш пароль для шифрування поточної часової позначки та додає його до AS-REQ. Сервер розшифровує часову позначку і перевіряє, що вона знаходиться в межах дозволеного часу перекосу; якщо дешифрування не вдалося, пароль негайно відхиляється. В іншому випадку TGT повертається в AS-REP.
  2. S1 намагається розшифрувати TGT за допомогою ключа, створеного з вашого пароля. Якщо розшифрування вдалося, пароль приймається як правильний.
  3. TGT зберігається в новоствореному кеш-сховищі даних. (Ви можете перевірити $KRB5CCNAMEзмінну оточуючого середовища, щоб знайти кеш-пам'ять, або скористатися klistсписком її вмісту.)
• S1 використовує PAM для здійснення перевірок авторизації (залежно від конфігурації) та відкриття сеансу.
  • Якщо pam_krb5викликається на етапі авторизації, він перевіряє, чи ~/.k5loginіснує. Якщо це так, він повинен вказати клієнта Kerberos. В іншому випадку єдиний дозволений довіритель .username@DEFAULT-REALM

Другий логін:

• S1 надсилає ім'я користувача та SSH-запит на SH на S2
• S2 повертає доступні аутентичні механізми, один з яких "gssapi-with-mic" ¹
• S1 запитує квиток на , відправляючи TGS-REQ з TGT в KDC і отримуючи TGS-REP з службовим квитком від нього.host/s2.example.com@EXAMPLE.COM
• S1 генерує "AP-REQ" (запит автентифікації) і відправляє його на S2.
• S2 намагається розшифрувати запит. Якщо це вдається, відбувається автентифікація. (PAM не використовується для аутентифікації.)
  • Інші протоколи, такі як LDAP, можуть вибрати для шифрування подальшої передачі даних за допомогою "сеансового ключа", який був включений у запит; однак SSH вже домовився про власний рівень шифрування.
• Якщо аутентифікація проходить успішно, S2 використовує PAM для здійснення перевірок авторизації та відкриття сеансу, як і S1.
• Якщо переадресація облікових даних була ввімкнена, а TGT має прапор "forwarddable", тоді S1 запитує копію TGT користувача (із набором прапор "перенаправлено") та відправляє його на S2, де він зберігається до нового кеша. Це дозволяє здійснювати рекурсивні реєстрації, підтверджені Kerberos.

Зверніть увагу, що ви також можете отримати TGT локально. У Linux ви можете це зробити за допомогою kinit, а потім підключити за допомогою ssh -K. Для Windows, якщо ви ввійшли в домен Windows AD, Windows робить це для вас; в іншому випадку можна використовувати MIT Kerberos . PuTTY 0.61 підтримує використання як Windows (SSPI), так і MIT (GSSAPI), хоча ви повинні включити пересилання (делегування) вручну.

¹ gssapi-keyex також можливий, але не був прийнятий до офіційного OpenSSH.

Якщо коротко сказати: ідеально, квитки на Kerberos повинні бути отримані на вашому терміналі (L), або з kinitкомандою, або як частина локальної послідовності входу в так званій установці "єдиного входу". Потім віддалені системи (S1, S2) будуть доступні без підказок пароля. Ланцюговий доступ (L → S1 → S2) можливий, використовуючи техніку, відому як "пересилання квитків". Таке налаштування вимагає, зокрема, KDC бути безпосередньо доступним з терміналу (L).

Інша відповідь, що базується, детально пояснює цей підхід.

Єдиним неочевидним кроком тут є те, що на S1 є модуль PAM, який використовував ваші облікові дані для виконання kinitі отримує вам квиток, що надає квиток від K (автентифікація клієнта). Потім, коли ви SSH на S2 використовуєте автентифікацію Kerberos, відбувається аутентифікація служби клієнта. Я не бачу користі переглядати всі нудні обміни повідомлення за повідомленням.

Кидок -vvvна вашій команді SSH , якщо ви хочете побачити кожне повідомлення і прочитати опис в Вікіпедії про Kerberos.