Como redefinir o Keytab para o FreeIPA Server e Client

4

Eu segui a documentação padrão para instalar o servidor e o cliente FreeIPA nos hosts 'SRV' e 'CLT' respectivamente. Em seguida, adicionei um usuário 'X' ao FreeIPA usando a interface do usuário da web. Agora, quando eu tento SSH como X para CLT, recebo um erro 'Permission denied, please try again.' . Eu marquei '/ var / log / messages' no cliente e vi isso - '[sssd[krb5_child[3277]]]: Decrypt integrity check failed' .

Eu reconfixo a senha várias vezes, mas isso não resolveu o problema. Então me deparei com estes -

Parece que remover o arquivo '/etc/krb5.keytab' do SRV e do CLT e recriá-los resolverá o problema.

  1. Como devo proceder para redefinir o keytab?
  2. Devo primeiro desprovisionar / remover o CLT do inventário do FreeIPA?
por Quest Monger 18.03.2014 / 13:46

4 respostas

4

Qual método de autenticação SSH você está usando? Você está digitando sua senha ou tentando usar a autenticação baseada em tíquete Kerberos (gssapi-com-mic ou gssapi-keyex)?

A mensagem "decodificar a verificação de integridade falhou" pode vir de duas fontes. Se você der a senha errada (sua senha não corresponde às chaves do seu principal no KDC), você conseguirá isso. Você também pode obtê-lo se a sua senha estiver correta, mas a tecla no servidor está desatualizada; isso aconteceria com autenticação de ticket e senha (porque com uma senha, o servidor obtém um ticket para seu próprio host depois de fazer kinit, para autenticar o KDC).

Sounds like removing the ’/etc/krb5.keytab’ file from SRV and CLT and then recreating them will solve the problem.

O keytab no cliente é irrelevante; não faz parte desse cenário. O provável problema aqui é que o keytab no servidor está fora de sincronia com o KDC (o servidor de autenticação Kerberos, ou "Key Distribution Center", que faz parte do FreeIPA). Com o Kerberos, todas as identidades (ou "principais") do sistema possuem chaves que compartilham com o KDC. As chaves de um usuário são geradas a partir de sua senha. As chaves para um serviço de software como o sshd são geradas aleatoriamente e armazenadas em um arquivo chamado keytab (para "tabela de chaves") para que o serviço possa acessá-las. Parece que as chaves do principal SSH foram alteradas no KDC, mas o keytab não foi atualizado para corresponder. Seu nome principal é do formato user @ REALM. O nome principal para o serviço SSH é do host de formulário / hostname @REALM. Experimente:

$ ipa-getkeytab -s <FreeIPA server> -p host/<hostname>@REALM -k <keytab file>.

... para extrair as chaves atuais para o principal de serviço SSH em um novo keytab. Você pode usar klist -ek <keytab> para visualizar o conteúdo dos antigos e novos keytabs. Se você tiver uma incompatibilidade de chave, ela deve aparecer como as chaves para o mesmo principal com números de versão de chave diferentes (ou “kvno”). Você pode ver algo como:

# look at the system keytab
$ sudo klist -ek
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)

# look at the new keytab
$ klist -ek <new keytab>
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
    
por 20.03.2014 / 07:47
1

Eu também resolvi esse problema. porque ccache continha uma chave antiga para o servidor IPA da instalação anterior só precisa apagar o arquivo /var/lib/sss/db/ccache_*

mais detalhes no ticket: link

    
por 10.12.2016 / 10:18
-1

No cliente, excluí /etc/krb5.keytab No servidor eu apaguei o host ipa host-del host.example.com

Eu desinstalo o software cliente ipa.

Eu reinstalo o cliente ipa

MAS, o cliente não funciona.

A t Por último, tive que reiniciar o ipa-server ipactl restart e ...

O cliente funciona bem. Eu suponho que o servidor kdc o similar tinha algo no cache sobre as chaves do cliente.

Atenciosamente.

    
por 04.02.2016 / 14:13
-1
  • rm /etc/krb5.keytab
  • kinit admin
  • ipa-getkeytab -s ipahostname.mydomain.com -p host/[email protected] -k /etc/krb5.keytab
  • systemctl reinicia sssd
por 27.11.2018 / 15:41