Назад | Перейти на главную страницу

Как Kerberos работает с SSH?

Предположим, у меня есть четыре компьютера, портативный компьютер, Server1, Server2, сервер Kerberos:

Опишите все важные обмены протоколами SSH и KRB5: «L отправляет имя пользователя на S1», «K отправляет ... на S1» и т. Д.

(Этот вопрос предназначен для редактирования сообществом; пожалуйста, улучшите его для неопытного читателя.)

Первый вход:

  • L отправляет имя пользователя и запрос аутентификации SSH на S1
  • S1 возвращает доступные механизмы аутентификации SSH, одним из которых является "пароль".
  • L выбирает "пароль" и отправляет простой пароль на S1.
  • S1 передает имя пользователя и пароль стеку PAM.
  • На S1 PAM (обычно pam_krb5 или pam_sss) запрашивает TGT (билет для выдачи билетов) от Kerberos KDC.
    1. S1 получает TGT.
      • Старый стиль (без предварительной аутентификации): S1 отправляет AS-REQ и получает AS-REP, содержащий TGT.
      • Новый стиль (с преаутентификацией): S1 использует ваш пароль для шифрования текущей отметки времени и прикрепляет ее к AS-REQ. Сервер расшифровывает временную метку и проверяет, находится ли она в пределах допустимого временного сдвига; если расшифровка не удалась, пароль немедленно отклоняется. В противном случае в AS-REP возвращается TGT.
    2. S1 пытается расшифровать TGT, используя ключ, созданный на основе вашего пароля. Если расшифровка прошла успешно, пароль считается правильным.
    3. TGT сохраняется во вновь созданном кэше учетных данных. (Вы можете проверить $KRB5CCNAME переменная среды, чтобы найти ccache, или используйте klist чтобы перечислить его содержимое.)
  • S1 использует PAM для выполнения проверок авторизации (в зависимости от конфигурации) и открытия сеанса.
    • Если pam_krb5 вызывается на этапе авторизации, он проверяет, ~/.k5login существуют. Если это так, он должен указать клиентского участника Kerberos. В противном случае единственным разрешенным принципалом является имя пользователя@ПО УМОЛЧАНИЮ-РЕАЛМ.

Второй логин:

  • S1 отправляет имя пользователя и запрос аутентификации SSH на S2
  • S2 возвращает доступные механизмы аутентификации, одним из которых является "gssapi-with-mic" 1
  • S1 запрашивает билет для host/s2.example.com@ПРИМЕР.COM, отправив TGS-REQ с TGT в KDC и получив от него TGS-REP с билетом службы.
  • S1 генерирует «AP-REQ» (запрос аутентификации) и отправляет его на S2.
  • S2 пытается расшифровать запрос. В случае успеха аутентификация выполняется. (PAM не используется для аутентификации.)
    • Другие протоколы, такие как LDAP, могут выбрать шифрование дальнейшей передачи данных с помощью «сеансового ключа», который был включен в запрос; однако SSH уже согласовал свой собственный уровень шифрования.
  • Если аутентификация прошла успешно, S2 использует PAM для проверки авторизации и открытия сеанса, как и S1.
  • Если пересылка учетных данных была включена и TGT имеет флаг «пересылаемый», то S1 запрашивает копию пользовательского TGT (с установленным флагом «переадресовано») и отправляет ее на S2, где она сохраняется в новом ccache. Это позволяет рекурсивный вход с аутентификацией Kerberos.

Обратите внимание, что вы также можете получить TGT локально. В Linux это можно сделать с помощью kinit, затем подключитесь, используя ssh -K. В Windows: если вы вошли в домен Windows AD, Windows сделает это за вас; в противном случае, MIT Kerberos может быть использован. PuTTY 0.61 поддерживает использование как Windows (SSPI), так и MIT (GSSAPI), хотя вы должны включить пересылку (делегирование) вручную.

1 gssapi-keyex также возможно, но не был принят в официальный OpenSSH.

Короче говоря: в идеале билеты Kerberos должны быть получены на вашем терминале (L) либо с помощью kinit или как часть локальной последовательности входа в систему в так называемой настройке «единого входа». В этом случае удаленные системы (S1, S2) будут доступны без запроса пароля. Цепной доступ (L → S1 → S2) будет возможен с использованием метода, известного как «пересылка билетов». Такая установка требует, в частности, чтобы KDC был доступен напрямую с терминала (L).

Другой ответ похотливость подробно объясняет этот подход.

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

Бросить -vvv в вашей команде ssh, если вы хотите видеть каждое сообщение и читать Описание в Википедии Kerberos.