Início / server / Perguntas / 1163684
Accepted
Webtux
Asked: 2024-08-09 15:17:00 +0800 CST

Kerberos: KDC retornou sequência de erro: NO PREAUTH

  • 772

Olá especialistas em Kerberos :)

Instalei um servidor Kerberos no Debian Bookworm:

krb5-kdc/stable-security,now 1.20.1-2+deb12u2
krb5-kdc-ldap/stable-security,now 1.20.1-2+deb12u2
krb5-pkinit/stable-security,now 1.20.1-2+deb12u2
krb5-user/stable-security,now 1.20.1-2+deb12u2

A autenticação SSH para qualquer host da minha rede está funcionando perfeitamente usando GSSAPI e Kerberos. Sem problemas até agora. No entanto, ao tentar fazer login via SSH no próprio servidor Kerberos, não consigo fazer isso funcionar e não tenho certeza de qual é o problema aqui.

Isto é o que ssh -vvv ns01diz na tentativa de login no próprio servidor Kerberos de outro host (neste caso 192.168.10.7):

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
KDC returned error string: NO PREAUTH

E krb5kdc Debug log no servidor ao tentar fazer login:

Aug 09 09:08:51 ns01.example.com krb5kdc[4557](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.7: NO PREAUTH: authtime 0, etypes {rep=UNSUPPORTED:(0)} [email protected] for host/[email protected], Generic error (see e-text)

Ao fazer um login remoto em outro servidor na rede, é isso que o krb5kdc registra neste caso (com sucesso):

Aug 09 09:10:39 ns01.example.com krb5kdc[4557](info): TGS_REQ (1 etypes {aes256-cts-hmac-sha1-96(18)}) 192.168.10.7: ISSUE: authtime 1723186107, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, [email protected] for krbtgt/[email protected]

O keytab no próprio servidor é como qualquer outro host SSH remoto:

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   4 09.08.2024 08:16:50 host/[email protected] (aes256-cts-hmac-sha1-96) 
   4 09.08.2024 08:16:50 host/[email protected] (aes128-cts-hmac-sha1-96)

Alguma idéia de como depurar isso ainda mais?

Obrigado

kerberos

1 respostas

  1. Best Answer

    Provavelmente o principal do seu cliente está faltando o requires_pre_authsinalizador.

    Tradicionalmente, o Kerberos emitia TGTs sem qualquer autenticação, contando apenas com o fato de serem criptografados com a senha do cliente. Mas isso os torna vulneráveis ​​a ataques de força bruta de senha offline (o pessoal sofisticado do AD chama isso de "ASREP-roasting" ), então a pré-autenticação foi adicionada no Kerberos 5 para exigir que o cliente prove que conhece a senha antes de poder obtê-la. um TGT.

    A pré-autenticação é, no entanto, opcional e o KDC do MIT a exige apenas para principais que tenham o sinalizador mencionado acima definido. (Por exemplo, princípios baseados em keytab geralmente não precisam de pré-autenticação porque possuem chaves aleatórias que são inviáveis ​​de serem quebradas de qualquer maneira.)

    Kerberos trata isso um pouco como um recurso de política - quando você kinit, seu TGT recebe o Psinalizador para indicar que a pré-autenticação ocorreu, e o KDC ou serviços podem usá-lo para tomar decisões de acesso (assim como os sistemas SSO modernos podem diferenciar "registrado em usar um certificado" de "logado usando uma senha").

    Na verdade, quando um principal de serviçorequires_pre_auth for definido – o que normalmente seria não operacional, já que os serviços não adquirem TGTs – o KDC do MIT irá tratá-lo como um requisito para que o cliente desse serviço seja fortalecido usando pré-autorização. Se o seu usuário principal não tiver o sinalizador de pré-autenticação e você fizer o kinit sem pré-autenticação, não será permitido obter tickets para nenhum serviço que tenha o sinalizador de pré-autenticação.

    Portanto, você deve modprincgarantir que todos os principais de contas de usuário tenham a pré-autenticação ativada (tanto para esse problema quanto para segurança em geral) e talvez deva adicioná-la default_principal_flagsem seu arquivo kdc.conf. (Observe que o MIT Krb5 é altamente inconsistente na grafia dos nomes dos sinalizadores; kadmin e kdc.conf esperam entradas diferentes.) Depois disso, você deve kinitnovamente; em seguida, verifique quais sinalizadores são mostrados por klist -f.

    (Quanto aos principais de host e serviço - eles não precisam estritamente do sinalizador de pré-auth, quer atuem como clientes ou não, mas também não fará mal nenhum mantê-lo ativado; na verdade, pode ajudá-lo a capturar futuros situações em que um usuário de alguma forma desativou a pré-autorização novamente.)

    • 0

relate perguntas