У меня есть несколько хостов под управлением 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/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, необходимый для регистрации и последующего управления вторичными сетевыми интерфейсами, проходить через первичные интерфейсы (то есть сеть 192.168.1.0/24 )?

1 ответ1

1

Хотя 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.)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .