☰

Generación de Registros SSHFP en FreeIPA

tag-icon • tag-icon linux ssh ldap kerberos freeipa
Generación de Registros SSHFP en FreeIPA

MI CONFIGURACIÓN

Tengo un grupo de máquinas que ejecutan Centos 7.3 y estoy usando Kerberos/LDAP para la autenticación. Kerberos/LDAP están empaquetados en FreeIPA 4.4.0.

Todos los anfitriones tienen una dirección en192.168.1.0/24. Me referiré a esto como la red "primaria".

Algunos hosts tienen una dirección en192.168.2.0/24. Me referiré a esto como la red "secundaria". Para los hosts que tienen esta segunda interfaz, existen entradas A/PTR adicionales correspondientes en DNS que asocian un nombre de host secundario y la dirección IP secundaria. En todos los casos, el nombre de host secundario es<nombre de host principal>-eth1.

MI META

Estoy trabajando para implementar SSO en todo nuestro clúster. SSO funciona bien en la red principal, pero no en la red secundaria.

LO QUE HE HECHO HASTA AHORA: DEL LADO DEL SERVIDOR

Configuré el servidor de la siguiente manera:

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

Una vez completada la instalación del servidor, también tengo que agregar manualmente el siguiente registro PTR al DNS:

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

Tengo que hacer esto ya que, aparentemente, el--auto reversabandera ainstalación-servidor-ipano funciona (o, quizás más probablemente, no lo entiendo).

LO QUE HE HECHO HASTA AHORA: LADO DEL CLIENTE

Configuré mis máquinas cliente de la siguiente manera:

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

Al igual que con la instalación del servidor, también tuve que agregar manualmente registros PTR de DNS para los clientes. Los registros A directos, creados por FreeIPA, han estado bien en todos los casos.

Luego, para registrar el nombre de host secundario en FreeIPA, hice lo siguiente en el cliente:

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

Como antes, esto creó registros DNS A directos, pero tuve que agregar manualmente los registros DNS PTR correspondientes.

EL PROBLEMA

Donde tengo problemas es en la red secundaria. Por ejemplo, puedo SSH paraanfitrión-1de manera sin contraseña (es decir, SSO está funcionando en la red principal), pero no puedo usar SSH parahost-1-eth1sin contraseña (es decir, SSO no funciona en la red secundaria).

Hay dos mensajes que uno puede recibir de SSH:

  1. Un mensaje para aceptar una clave de host SSH desconocida
  2. Una solicitud de contraseña del usuario.

No se me solicita una contraseña de usuario cuando hago SSH a un host utilizando su nombre de host secundario. Es el mensaje para aceptar una clave de host SSH desconocida que no puedo eludir cuando intento utilizar SSH en un host utilizando su nombre de host secundario. Y esto está pasando porque...

He observado que no se generan registros DNS SSHFP para los nombres de host secundarios. Se deben asociar todas las mismas claves de host SSH con el nombre de host secundario que con el nombre de host principal. Sin embargo, esto no está sucediendo.

¿Cómo debo usar FreeIPA para generar los registros DNS SSHFP necesarios para los nombres de host secundarios? Evidentemente, más que elunirse a ipalo que estoy haciendo es necesario.

Respuesta1

Probablemente no sea la respuesta que le guste, pero también consideré los RR SSHFP en DNS, pero lo abandoné por las siguientes razones:

  1. Necesita soporte al cliente (ver opciónVerificarHostKeyDNSpara cliente OpenSSH).
  2. Debe firmar sus zonas DNS con DNSSEC y tener solucionadores locales para verificar que las firmas sean realmente seguras. De lo contrario, los registros DNS pueden falsificarse fácilmente.
  3. En algunos entornos más grandes es bastante difícil coordinar eso con las personas responsables de los servidores DNS. Tenga en cuenta que necesitará actualizaciones de DNS dinámicas si tiene muchos servidores SSH.

Recomiendo encarecidamente investigarCertificados OpenSSHpara permitir que una autoridad certificadora confiable firme todas las claves del host. Esto también necesita soporte del cliente (por ejemplo, no es compatible con PuTTY) y debe distribuir las claves públicas de SSH-CA a todos los clientes. Pero es más fácil que DNSSEC y, en mi humilde opinión, más seguro.

información relacionada