Использование Kerberos с несколькими хостами

453
Dave

У меня есть несколько хостов под управлением CentOS 7.3 с OpenSSH 6.6.1p1 и Kerberos 5 версии 1.14.1 .

Мои хосты и их сетевые интерфейсы показаны ниже. Хосты перечислены по их «первичному» имени хоста, которое является именем хоста, связанным в DNS с одним IP-адресом в сетевом интерфейсе eth0 хоста . На хостах с несколькими сетевыми интерфейсами я также даю имена DNS, связанные с одним IP-адресом на каждом из этих сетевых интерфейсов.

  • inf.example.com

    • eth0: 192.168.1.1/24
  • dev.example.com

    • eth0: 192.168.1.2/24
  • cluster-1.example.com

    • eth0: 192.168.1.11/24
    • eth1: 192.168.10.11/24 (записи DNS A / PTR для этого вторичного сетевого интерфейса настраиваются с использованием имени хоста cluster-1-a.example.com)
  • cluster-2.example.com

    • eth0: 192.168.1.12/24
    • eth1: 192.168.10.12/24 (записи DNS A / PTR для этого вторичного сетевого интерфейса настраиваются с использованием имени хоста cluster-2-a.example.com)

inf.example.com, сервер «инфраструктуры», - это сервер DNS, LDAP, Центр распространения ключей Kerberos (KDC) и т. д. Все эти элементы управляются унифицированно с помощью FreeIPA версии 4.4.0 .

dev.example.com - это узел разработки, с которого разработчики запускают сценарии, использующие SSH для выполнения удаленных команд на cluster-1.example.com .

Команда, которая выполняется на cluster-1.example.com, в свою очередь, использует SSH для выполнения удаленной команды на другом узле кластера, но делает это через свой вторичный сетевой интерфейс (то есть через свой 192.168.10.11 (он же cluster-2-a). .example.com ) сетевой интерфейс).

Чтобы облегчить запуск этих сценариев, я пытаюсь полностью настроить единый вход (SSO) для OpenSSH.

Все работает нормально, если я использую адреса 192.168.1.0/24 и использую флаг -K для SSH для пересылки моего билета на выдачу билетов Kerberos (TGT) на хост, на котором я работаю SSH:

user@dev$ ssh -K cluster-1.example.com user@cluster-1$ ssh -K cluster-2.example.com user@cluster-2 $ # Everything worked! I was never prompted to accept an SSH host key or to enter a password! 

Однако, если я пытаюсь использовать вторичный сетевой интерфейс на втором прыжке SSH, все работает не так, как хотелось бы (то есть таким образом, который не требует взаимодействия с человеком). В частности, возникают два запроса на взаимодействие с человеком:

  1. Мне предлагается принять ключ хоста SSH сервера
  2. Мне предлагают пароль

Эти проблемы можно увидеть ниже:

user@dev$ ssh -K cluster-1.example.com user@cluster-1$ ssh -K cluster-2-a.example.com The authenticity of host 'cluster-2-a.example.com (<no hostip for proxy command>)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cluster-2-a.example.com' (RSA) to the list of known hosts. Password: 

Не удивительно, что это не работает. Хотя IP-адреса и имена хостов, связанные с интерфейсами вторичной сети, имеют соответствующие записи A и PTR в DNS, «регистрация» IP-адресов и имен хостов, связанных с интерфейсами вторичной сети в Kerberos, отсутствует.

Как правильно настроить в Kerberos хосты с несколькими сетевыми интерфейсами / именами хостов / IP-адресами, чтобы SSO SSO мог работать с любым из имен хостов / IP-адресов хостов?

31.07.2008 ОБНОВЛЕНИЕ
inf.example.com (т.е. KDC) не присутствует в сети 192.168.10.0/24 .

Требуется ли присутствие на 192.168.10.0/24 для 1) первоначальной регистрации cluster-1-a.example.com и cluster-2-a.example.com или для 2) текущих операций cluster-1-a.example .com и cluster-2-a.example.com ?

Или, может ли весь трафик Kerberos, необходимый для регистрации и последующего управления вторичными сетевыми интерфейсами, проходить через первичные интерфейсы (т. Е. Сеть 192.168.1.0/24 )?

0

1 ответ на вопрос

1
grawity

Хотя IP-адреса и имена хостов, связанные с интерфейсами вторичной сети, имеют соответствующие записи A и PTR в DNS, «регистрация» IP-адресов и имен хостов, связанных с интерфейсами вторичной сети в Kerberos, отсутствует.

Хорошо, зарегистрируй их.

  1. На каждом многосетевом сервере отключите строгую проверку принципала и скажите ему принимать билеты для любого ключа, который присутствует в его таблице ключей:

  2. После этого добавьте принципалы для всех имен серверов в KDC, а ключи для всех них - в одно и то же /etc/krb5.keytab. (Для клиентов с отключенной канонизацией имен можно даже добавить принципалы для коротких имен и / или IP-адресов.)

    Похоже, что во FreeIPA есть функция под названием «основные псевдонимы», хотя я не уверен, работает ли она здесь как нужно:

    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/managing-kerberos-aliases

Это, вероятно, не единственный способ, но он самый простой и не требует какой-либо конфигурации на стороне клиента. Все просто работает как раньше.

31/31/2018 ОБНОВЛЕНИЕ

inf.example.com (то есть KDC) не присутствует в сети 192.168.10.0/24.

Требуется ли присутствие на 192.168.10.0/24 для 1) первоначальной регистрации cluster-1-a.example.com и cluster-2-a.example.com или для 2) текущих операций cluster-1-a.example .com и cluster-2-a.example.com?

Нет, это не так. Kerberos не заботится о подсетях в малейшей степени - это зависит только от стандартной работы одноадресных соединений TCP / UDP. (Например, у моей homelab есть серверы и KDC в трех разных странах, которые общаются через общедоступный Интернет ...)

В этом отношении серверы вообще не связываются с KDC . Только клиенты делают. Сервер использует свою локальную таблицу ключей для подтверждения вашего билета.

(Конечно, сервер будет связываться с вашими службами каталогов FreeIPA для поиска сведений об учетной записи через LDAP ... но это уже не Kerberos.)

Скорее всего, я приму это как ответ, когда узнаю достаточно, чтобы поступить так, как вы предложили в соответствии с требованиями FreeIPA. Я все еще на кривой обучения Kerberos / FreeIPA. Есть ли какие-либо последствия для безопасности для этого предложения? Dave 5 лет назад 0
Не должно быть ни одного, по крайней мере, до тех пор, пока у keytab есть только альтернативные участники для той же службы. (Системы Active Directory делают это по умолчанию, причем один и тот же ключ используется для всех принципалов хоста. Я подозреваю, что функция «псевдонимов» FreeIPA делает то же самое.) Тем не менее, просмотрите документы MIT Kerberos, связанные выше. grawity 5 лет назад 0
Медленно продвигаясь вперед в этом. Пожалуйста, смотрите обновление от 31.07.2008 до моего исходного поста. Спасибо! Dave 5 лет назад 0
Вероятно, это должен быть отдельный вопрос, но, короче говоря, подсети совершенно не имеют значения. grawity 5 лет назад 0

Похожие вопросы