Noções básicas do cliente Kerberos no Linux: krb5.conf, kinit/klist/kdestroy e keytabs

Objetivo

Obter, inspecionar e limpar um ticket-granting ticket (TGT) do Kerberos em um cliente Linux com MIT Kerberos (krb5), e usar uma keytab em um processo que precisa se autenticar sem senha interativa.

Pré-requisitos

O pacote krb5-user/krb5-workstation instalado; /etc/krb5.conf configurado com pelo menos um default_realm em [libdefaults]; uma seção [realms] que associe o realm ao seu KDC, a menos que registros DNS SRV forneçam essa informação; normalmente também uma seção [domain_realm] que associe domínios DNS ao realm; e acesso de rede ao KDC (em geral TCP/UDP 88).

Passos

1. Confirme a configuração: o default_realm em /etc/krb5.conf deve corresponder ao nome do realm exatamente, inclusive em maiúsculas e minúsculas. Por convenção, nomes de realm Kerberos são escritos em maiúsculas e tratados como strings sensíveis a maiúsculas e minúsculas; assim, EXAMPLE.COM e example.com são realms diferentes para a biblioteca, mesmo que o DNS não faça essa distinção.
2. Obtenha um ticket de forma interativa: kinit user@EXAMPLE.COM, que pede a senha e, se der certo, grava um TGT no cache de credenciais padrão. A documentação do kinit descreve -k -t <keytab> para autenticar com uma keytab em vez de senha, que é a forma necessária para uso sem intervenção humana, por exemplo kinit -k -t /etc/svc.keytab svc@EXAMPLE.COM (sem indicar um principal, o padrão é o principal local host/).
3. Inspecione o cache: klist mostra o principal, as flags do ticket e os horários de emissão e expiração, sem exigir nova autenticação.
4. Liste o conteúdo de uma keytab (de um serviço ou de um principal de automação) sem extrair segredos: klist -k -t -e /etc/krb5.keytab, que exibe os principais, os timestamps das chaves e, com -e, os tipos de criptografia presentes na keytab; a keytab do sistema só pode ser lida pelo root.
5. Descarte os tickets em cache ao terminar ou antes de trocar de identidade: kdestroy.

Resultado esperado

Depois de um kinit bem-sucedido, o klist mostra um TGT válido com horário de expiração no futuro; uma chamada posterior a um serviço com Kerberos (SSH com GSSAPI, um bind LDAP SASL/GSSAPI) funciona sem pedir senha. Após kdestroy, o klist informa que não há credenciais em cache.

Limites e base de verificação

As falhas mais comuns no lado do cliente são a diferença de relógio e a divergência de maiúsculas e minúsculas no nome do realm entre o krb5.conf e o que o KDC espera. No primeiro caso, o Kerberos rejeita tickets quando os relógios do cliente e do KDC diferem mais do que a tolerância configurada (clockskew em [libdefaults], padrão de 300 segundos), e o erro é reportado como "clock skew too great". Nenhum dos dois é um problema de rede ou de senha, portanto verificar primeiro chronyc tracking/timedatectl e a string exata do realm economiza tempo. Uma keytab dá a quem consegue lê-la a capacidade de obter tickets para o seu principal; por isso as permissões do arquivo (leitura apenas pelo dono) importam tanto quanto o local onde ele fica.