☰

Генерация записей SSHFP в FreeIPA

tag-icon • tag-icon linux ssh ldap kerberos freeipa
Генерация записей SSHFP в FreeIPA

МОЯ НАСТРОЙКА

У меня есть кластер машин под управлением Centos 7.3, и я использую Kerberos / LDAP для аутентификации. Kerberos / LDAP упакованы в FreeIPA 4.4.0.

Все хосты имеют адрес на192.168.1.0/24. Я буду называть это «первичной» сетью.

Некоторые хосты имеют адрес в192.168.2.0/24. Я буду называть это «вторичной» сетью. Для хостов, которые имеют этот второй интерфейс, есть соответствующие дополнительные записи A / PTR в DNS, которые связывают вторичное имя хоста и вторичный IP-адрес. Во всех случаях вторичное имя хоста —<основное имя хоста>-eth1.

МОЯ ЦЕЛЬ

Я работаю над внедрением SSO в нашем кластере. SSO работает нормально в основной сети, но не во вторичной.

ЧТО Я СДЕЛАЛ НА ДАННЫЙ МОМЕНТ: СЕРВЕРНАЯ СТОРОНА

Я настроил сервер следующим образом:

ipa-server-install \
-r ME.EXAMPLE.COM \
-n me.example.com \
--mkhomedir \
--hostname=host-1.me.example.com \
--ip-address=192.168.1.1 \
--ssh-trust-dns \
--setup-dns \
--auto-forwarders \
--forward-policy=only \
--auto-reverse \
--dirsrv-cert-file=<path to server SSL certificate> \
--http-cert-file=<path to server SSL certificate> \
--no-dnssec-validation

После завершения установки сервера мне также придется вручную добавить следующую PTR-запись в DNS:

1.1.168.192.in-addr.arpa PTR host-1.me.example.com

Мне приходится это делать, поскольку, по-видимому,--автореверсфлаг вipa-сервер-установкане работает (или, что более вероятно, я этого не понимаю).

ЧТО Я СДЕЛАЛ НА СЕЙЧАС: СТОРОНА КЛИЕНТА

Я настроил свои клиентские машины следующим образом:

ipa-client-install \
--force-ntpd \
-p admin \
-W \
--mkhomedir \
--no-nisdomain \
--ssh-trust-dns

Как и при установке сервера, мне также пришлось вручную добавлять записи DNS PTR для клиентов. Записи пересылки A, созданные FreeIPA, были в порядке во всех случаях.

Затем, чтобы зарегистрировать вторичное имя хоста в FreeIPA, я сделал следующее на клиенте:

kinit admin
ipa-join -h host-1-eth1.me.example.com

Как и прежде, это создало записи DNS A для пересылки, но мне пришлось вручную добавить соответствующие записи DNS PTR.

ПРОБЛЕМА

У меня проблема с вторичной сетью. Например, я могу подключиться по SSH кхост-1без пароля (т.е. SSO работает в основной сети), но я не могу подключиться по SSHхост-1-eth1без пароля (т.е. SSO не работает во вторичной сети).

SSH может выдать два запроса:

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

Мне не предлагается ввести пароль пользователя, когда я подключаюсь по SSH к хосту, используя его вторичное имя хоста. Это запрос на принятие неизвестного ключа хоста SSH, который я не могу обойти, пытаясь подключиться по SSH к хосту, используя его вторичное имя хоста. И это происходит потому, что...

Я заметил, что для вторичных имен хостов не генерируются записи SSHFP DNS. Все те же ключи хоста SSH должны быть связаны со вторичным именем хоста, что и с первичным именем хоста. Однако этого не происходит.

Как мне использовать FreeIPA, чтобы получить необходимые записи SSHFP DNS, сгенерированные для вторичных имен хостов? Очевидно, что больше, чемipa-присоединитьсяЯ делаю то, что нужно.

решение1

Возможно, это не тот ответ, который вам понравится, но я также рассматривал возможность использования записей ресурсов SSHFP в DNS, но отказался от этой идеи по следующим причинам:

  1. Требуется поддержка клиента (см. вариантVerifyHostKeyDNSдля клиента OpenSSH).
  2. Вам необходимо подписать свои DNS-зоны с помощью DNSSEC и иметь локальные резолверы для проверки подписей, чтобы быть действительно безопасными. В противном случае DNS-записи могут быть легко подделаны.
  3. В некоторых более крупных средах довольно сложно координировать это с людьми, ответственными за DNS-серверы. Имейте в виду, что вам понадобятся динамические обновления DNS, если у вас много SSH-серверов.

Я настоятельно рекомендую рассмотретьСертификаты OpenSSHчтобы доверенный центр сертификации подписывал все ключи хоста. Это также требует поддержки клиентов (например, не поддерживается в PuTTY), и вам придется распространять открытый ключ(и) SSH-CA всем клиентам. Но это проще, чем DNSSEC и, IMHO, более безопасно.

Связанный контент