Как Kerberos работает с 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 (билет для выдачи билетов) из Kerberos KDC.
  1. S1 получает TGT.
     • Старый стиль (без предварительного подтверждения): S1 отправляет AS-REQ и получает AS-REP, содержащий TGT.
     • Новый стиль (с предаварием): S1 использует ваш пароль для шифрования текущей метки времени и прикрепляет ее к AS-REQ. Сервер расшифровывает метку времени и проверяет, что она находится в пределах допустимого перекоса времени; если расшифровка не удалась, пароль немедленно отклоняется. В противном случае TGT возвращается в AS-REP.
  2. S1 пытается расшифровать TGT, используя ключ, сгенерированный из вашего пароля. Если расшифровка завершается успешно, пароль принимается как правильный.
  3. TGT сохраняется во вновь созданном кэше учетных данных. (Вы можете проверить $KRB5CCNAMEпеременную среды, чтобы найти ccache, или использовать klistдля просмотра его содержимого.)
• S1 использует PAM для выполнения проверок авторизации (в зависимости от конфигурации) и открытия сеанса.
  • Если pam_krb5вызывается на этапе авторизации, он проверяет, ~/.k5loginсуществует ли . Если это так, он должен перечислить клиентский принципал Kerberos. В противном случае единственный допустимый принципал .username@DEFAULT-REALM

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

• S1 отправляет запрос имени пользователя и SSH на 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 имеет флаг «forwardable», то S1 запрашивает копию TGT пользователя (с установленным флагом «forwarded») и отправляет ее на S2, где он сохраняется в новом ccache. Это позволяет рекурсивно входить в систему с аутентификацией 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 в Википедии .