Usando o Kerberos com hosts multi-homed

Question

Eu tenho vários hosts rodando CentOS 7.3 com OpenSSH 6.6.1p1 e Kerberos 5 versão 1.14.1 .

Meus hosts e suas interfaces de rede são mostrados abaixo. Os hosts são listados por seu nome de host "principal", que é o nome do host associado no DNS com o endereço IP único na interface de rede eth0 do host. Em hosts com várias interfaces de rede, eu também forneço os nomes DNS associados ao endereço IP único em cada uma dessas interfaces de rede.

• 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 (os registros DNS A / PTR para esta interface de rede secundária são configurados usando o nome de host cluster-1-a.example.com)

• cluster-2.example.com

  • eth0: 192.168.1.12/24
  • eth1: 192.168.10.12/24 (os registros DNS A / PTR para esta interface de rede secundária são configurados usando o nome do host cluster-2-a.example.com)

inf.example.com , o servidor de "infra-estrutura", é onde o DNS, o LDAP, o Centro de distribuição de chaves Kerberos (KDC), etc. são executados. Esses itens são todos gerenciados de maneira unificada através do uso do FreeIPA versão 4.4.0 .

dev.example.com é um host de desenvolvimento do qual os desenvolvedores executam scripts que usam o SSH para executar comandos remotos no cluster-1.example.com .

O comando que é executado no cluster-1.exemplo.com , por sua vez, usa o SSH para executar um comando remoto no outro host do cluster, mas o faz ao longo do Interface de rede secundária (ou seja, através de sua interface de rede 192.168.10.11 (também conhecida como cluster-2-a.example.com )).

Para facilitar a execução desses scripts, estou tentando configurar o Single Sign On (SSO) para o OpenSSH.

Tudo está funcionando bem se eu usar os endereços 192.168.1.0/24 e usar o sinalizador -K para que o SSH envie meu ticket de concessão de tíquete do Kerberos (TGT) para o host para o qual sou 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!

No entanto, se eu tentar usar a interface de rede secundária no segundo salto SSH, as coisas não funcionam como desejado (ou seja, de uma forma que não requer interação humana). Especificamente, dois prompts para interação humana ocorrem:

1. Recebo uma solicitação para aceitar a chave do host SSH do servidor
2. Solicito minha senha

Estes problemas podem ser vistos abaixo:

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:

Não é de surpreender que isso não esteja funcionando. Embora os endereços IP e nomes de host associados às interfaces de rede secundárias tenham registros A e PTR correspondentes no DNS, não há "inscrição" dos endereços IP e nomes de host associados às interfaces de rede secundárias no Kerberos.

Como os hosts com várias interfaces de rede / nomes de host / endereços IP estão configurados corretamente no Kerberos para permitir que o SSO SSO funcione usando qualquer um dos nomes de host / endereços IP dos hosts?

7/31/2018 ATUALIZAÇÃO
inf.example.com (ou seja, o KDC) não tem presença no 192.168.10.0/ 24 rede.

Precisa de presença 192.168.10.0/24 para 1) Inscrição inicial de cluster-1-a.example.com e cluster-2 -a.example.com ou para 2) operações contínuas de cluster-1-a.example.com e cluster-2-a.example.com ?

Ou, todo o tráfego de Kerberos necessário para registrar e operar as interfaces de rede secundárias flui pelas interfaces principais (ou seja, a rede 192.168.1.0/24 )?

    

Answer 1

Though the IP addresses and hostnames associated with the secondary network interfaces have corresponding A and PTR records in DNS, there is no "enrollment" of the IP addresses and hostnames associated with the secondary network interfaces in Kerberos.

Bem, inscreva-os.

1. Em cada servidor com hospedagem múltipla, desative a verificação principal restrita e diga a ela para aceitar tickets para qualquer chave presente em seu keytab:

   • Globalmente (para todos os serviços) em /etc/krb5.conf (para o MIT Kerberos; o Heimdal pode ter um nome diferente para ele):

     [libdefaults]
         ignore_acceptor_hostname = true
     

     Documentado em:

     link link

   • Ou apenas para SSH, em /etc/ssh/sshd_config (para OpenSSH):

     GSSAPIStrictAcceptorCheck no
     

     Documentado em:

     link link

2. Depois de fazer isso, adicione os principais para todos os nomes do servidor ao KDC e as chaves para todos eles no mesmo /etc/krb5.keytab . (Para clientes que possuem canonização de nome desativada, você pode até mesmo adicionar entidades para nomes abreviados e / ou endereços IP.)

   O FreeIPA parece ter um recurso chamado "alias principais" para fazer isso, embora não tenha certeza se ele funciona conforme necessário aqui:

   link

Este provavelmente não é o método somente , mas é o mais simples e não envolve nenhuma configuração do lado do cliente. Tudo funciona como antes.

7/31/2018 UPDATE

inf.example.com (i.e. the KDC) does not have a presence on the 192.168.10.0/24 network.

Does it need a presence on 192.168.10.0/24 for 1) Initial enrollment of cluster-1-a.example.com and cluster-2-a.example.com or for 2) ongoing operations of cluster-1-a.example.com and cluster-2-a.example.com?

Não, isso não acontece. O Kerberos não se preocupa com as sub-redes no mínimo - isso depende apenas do trabalho de comunicações unicast TCP / UDP padrão. (Por exemplo, meu homelab tem servidores e KDCs em três países separados, comunicando-se pela Internet pública ...)

Aliás, os servidores não se comunicam com o KDC . Somente os clientes o fazem. O servidor usa seu keytab local para verificar seu ticket.

(Claro, o servidor irá se comunicar com seus serviços de diretório FreeIPA para procurar detalhes da conta via LDAP ... mas isso não é mais uma coisa do Kerberos.)