主页 / server / 问题 / 1163684
Accepted
Webtux
Asked: 2024-08-09 15:17:00 +0800 CST

Kerberos：KDC 返回错误字符串：NO PREAUTH

  • 772

您好，kerberos 专家:)

我已经在 Debian Bookworm 上安装了 kerberos 服务器：

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

使用 GSSAPI 和 Kerberos 对我网络上的任何主机进行 SSH 身份验证都很顺利。到目前为止没有问题。但是，当尝试通过 SSH 登录到 kerberos 服务器本身时，我无法让它工作，我不确定这里的问题是什么。

这是ssh -vvv ns01从另一台主机（此例为 192.168.10.7）尝试登录 kerberos 服务器本身时显示的内容：

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

并在尝试登录时在服务器上进行 krb5kdc 调试登录：

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)

当远程登录到网络内的另一台服务器时，这是 krb5kdc 在这种情况下记录的内容（成功）：

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]

服务器本身上的 keytab 与任何其他远程 ssh 主机一样：

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)

对于如何进一步调试这个问题，有什么想法吗？

谢谢

kerberos

1 个回答

  1. Best Answer

    您的客户负责人很可能遗失了该requires_pre_auth标志。

    传统上，Kerberos 会在不进行任何身份验证的情况下颁发 TGT，仅依赖于它们已使用客户端密码加密的事实。但这会使它们容易受到离线密码暴力攻击（花哨的 AD 人员称之为“ASREP-roasting”），因此在 Kerberos 5 中添加了预身份验证，要求客户端证明它知道密码，然后才能获得 TGT。

    但是，预认证是可选的，MIT KDC 仅要求已设置上述标志的主体进行预认证。（例如，基于 keytab 的主体通常不需要预认证，因为它们具有随机密钥，无论如何都无法破解。）

    Kerberos 将其视为一种策略功能 - 当您 kinit 时，您的 TGT 会获得标志P以表明预认证已发生，并且 KDC 或服务可以使用它来做出访问决策（非常类似于现代 SSO 系统可以区分“使用证书登录”和“使用密码登录”）。

    事实上，当设置了服务主体时requires_pre_auth（这通常是无操作的，因为服务不会获取 TGT），MIT KDC 会将其视为该服务客户端使用预认证进行强化的要求。如果您的用户主体没有预认证标志，并且您在没有预认证的情况下进行 kinit，那么您将无法获得任何具有预认证标志的服务的票证。

    因此，您应该检查modprinc所有用户帐户主体是否已启用预认证（既为了解决这个问题，也为了保证总体安全），并且可能应该将其添加到default_principal_flags您的 中kdc.conf。 （请注意，MIT Krb5 在标志名称的拼写上高度不一致；kadmin 和 kdc.conf 需要不同的输入。）此后，您必须kinit再次；然后检查 显示了哪些标志klist -f。

    （至于主机和服务主体 - 它们并不严格需要预认证标志，无论它们是否也充当客户端，但保持它启用也不会有任何损害；事实上它可能有助于您捕捉到未来用户以某种方式再次禁用预认证的情况。）

    • 0

相关问题