Использование Kerberos с несколькими хостами
У меня есть несколько хостов под управлением 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) на хост, на котором я SSHing:
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, все работает не так, как хотелось бы (то есть таким образом, который не требует взаимодействия с человеком). В частности, возникают два запроса на взаимодействие с человеком:
- Мне предлагается принять ключ хоста SSH сервера
- Мне предлагают пароль
Эти проблемы можно увидеть ниже:
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)?
1 ответ
Хотя IP-адреса и имена хостов, связанные с вторичными сетевыми интерфейсами, имеют соответствующие записи A и PTR в DNS, "регистрация" IP-адресов и имен хостов, связанных с вторичными сетевыми интерфейсами, в Kerberos отсутствует.
Хорошо, зарегистрируй их.
На каждом многосетевом сервере отключите строгую основную проверку и скажите ему принимать билеты для любого ключа, который присутствует в его таблице ключей:
Глобально (для всех услуг) в
/etc/krb5.conf
(для MIT Kerberos; у Heimdal может быть другое имя):[libdefaults] ignore_acceptor_hostname = true
Документировано в:
http://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html
Или только для SSH, в
/etc/ssh/sshd_config
(для OpenSSH):GSSAPIStrictAcceptorCheck no
Документировано в:
https://man.openbsd.org/sshd_config http://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html
После этого добавьте принципалы для всех имен серверов в KDC, а ключи для всех них - в один и тот же.
/etc/krb5.keytab
, (Для клиентов, у которых отключена канонизация имен, вы даже можете добавить принципалы для коротких имен и / или IP-адресов.)Похоже, что во FreeIPA есть функция под названием "основные псевдонимы", хотя я не уверен, работает ли она здесь как нужно:
Это, вероятно, не единственный способ, но он самый простой и не требует настройки на стороне клиента. Все просто работает как раньше.
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 не заботится о подсетях в малейшей степени - это зависит только от стандартной работы одноадресных соединений TCP/UDP. (Например, у моей homelab есть серверы и KDC в трех отдельных странах, которые общаются через общедоступный Интернет...)
В этом отношении серверы вообще не связываются с KDC . Только клиенты делают. Сервер использует свою локальную таблицу ключей для подтверждения вашего билета.
(Конечно, сервер будет связываться с вашими сервисами каталогов FreeIPA для поиска данных учетной записи через LDAP... но это уже не Kerberos.)