☰

Geração de registros SSHFP no FreeIPA

tag-icon • tag-icon linux ssh ldap kerberos freeipa
Geração de registros SSHFP no FreeIPA

MINHA CONFIGURAÇÃO

Tenho um cluster de máquinas rodando Centos 7.3 e estou usando Kerberos/LDAP para autenticação. Kerberos/LDAP são empacotados no FreeIPA 4.4.0.

Todos os hosts têm um endereço em192.168.1.0/24. Vou me referir a isso como rede "primária".

Alguns hosts têm um endereço em192.168.2.0/24. Vou me referir a isso como rede "secundária". Para hosts que possuem esta segunda interface, existem entradas A/PTR extras correspondentes no DNS que associam um nome de host secundário e o endereço IP secundário. Em todos os casos, o nome do host secundário é<nome do host primário>-eth1.

MEU GOL

Estou trabalhando para implementar o SSO em nosso cluster. O SSO está funcionando bem na rede primária, mas não na rede secundária.

O QUE FIZ ATÉ AGORA: LADO DO SERVIDOR

Configurei o servidor da seguinte forma:

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

Após a conclusão da instalação do servidor, também preciso adicionar manualmente o seguinte registro PTR ao DNS:

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

Eu tenho que fazer isso porque, aparentemente, o--auto reversãobandeira parainstalação do servidor ipanão funciona (ou, talvez mais provavelmente, não entendo).

O QUE FIZ ATÉ AGORA: LADO DO CLIENTE

Configurei minhas máquinas clientes da seguinte forma:

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

Assim como na instalação do servidor, também tive que adicionar manualmente registros DNS PTR para os clientes. Os registros A de encaminhamento, criados pelo FreeIPA, funcionaram bem em todos os casos.

Então, para registrar o nome do host secundário no FreeIPA, fiz o seguinte no cliente:

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

Como antes, isso criou registros DNS A de encaminhamento, mas tive que adicionar manualmente os registros DNS PTR correspondentes.

O PROBLEMA

Onde estou tendo problemas é na rede secundária. Por exemplo, posso usar SSH parahospedeiro-1sem senha (ou seja, o SSO está funcionando na rede primária), mas não consigo fazer SSH parahost-1-eth1sem senha (ou seja, o SSO não está funcionando na rede secundária).

Existem dois prompts que podem ser recebidos do SSH:

  1. Uma solicitação para aceitar uma chave de host SSH desconhecida
  2. Um prompt para a senha do usuário

Não sou solicitada uma senha de usuário quando faço SSH para um host usando seu nome de host secundário. É o prompt para aceitar uma chave de host SSH desconhecida que não consigo contornar ao tentar fazer SSH para um host usando seu nome de host secundário. E isso está acontecendo porque...

Observei que não há registros DNS SSHFP sendo gerados para os nomes de host secundários. Todas as mesmas chaves de host SSH devem ser associadas ao nome do host secundário e ao nome do host primário. No entanto, isso não está acontecendo.

Como devo usar o FreeIPA para obter os registros DNS SSHFP necessários gerados para os nomes de host secundários? Obviamente, mais do queadesão ao ipaque estou fazendo é necessário.

Responder1

Provavelmente não é a resposta que você gosta, mas também considerei RRs SSHFP no DNS, mas desisti pelos seguintes motivos:

  1. Necessita de suporte ao cliente (ver opçãoVerifiqueHostKeyDNSpara cliente OpenSSH).
  2. Você precisa assinar suas zonas DNS com DNSSEC e ter resolvedores locais para verificar se as assinaturas são realmente seguras. Caso contrário, os registros DNS podem ser facilmente falsificados.
  3. Em alguns ambientes maiores é muito difícil coordenar isso com as pessoas responsáveis ​​pelos servidores DNS. Tenha em mente que você precisaria de atualizações dinâmicas de DNS se tivesse muitos servidores SSH.

Eu recomendo fortemente que você analiseCertificados OpenSSHpara permitir que uma autoridade de certificação confiável assine todas as chaves do host. Isso também precisa de suporte ao cliente (por exemplo, não suportado no PuTTY) e você deve distribuir a(s) chave(s) pública(s) do SSH-CA para todos os clientes. Mas é mais fácil que DNSSEC e IMHO mais seguro.

informação relacionada