Kerberos HOWTO 中经常会出现类似这样的词语：
安全地将 keytab 传输（通过闪存驱动器、磁盘或加密连接）到客户端主机。
以 root 身份登录客户端主机、运行 kinit 以获取管理帐户的凭据以及从客户端运行 kadmin 是否还不够好？
答案1
我认为这主要是旧版 MIT Kerberos 的遗留问题，旧版 MIT Kerberos 确实存在安全问题或功能较低（kadmin在网络模式下，很多功能都无法实现；您必须kadmin.local在主 KDC 上运行）。当然，Heimdal 从未考虑过任何此类限制，事实上，他还对流程进行了一些简化和优化（ktutil get）。此外，许多官方 MIT Kerberos 文档都假设了很多我在实际使用中很少见到的偏执，例如假设任何安全凭证都是手动从一个系统复制到另一个系统。
答案2
MIT 的“ktadd 问题”也与此相关。MIT kadmin ktadd 命令不会从 KDC 中提取密钥；相反，它会生成新密钥，将其写入密钥表，然后替换 KDC 中主体的密钥。只有 kadmin.local 才有能力提取密钥；kadmin RPC 接口根本不会返回它们。这被吹捧为一项安全功能，可防止受损的 kadmin 帐户读取每个人的密钥。问题是，这意味着一个错误的 ktadd 命令将破坏正在运行的服务：如果它没有更新正确的密钥表，KDC 会立即开始使用该服务没有的新密钥签发票证。如果您有多个用于同一服务的服务器（例如在负载平衡器后面），您不能一个接一个地访问它们并使用 ktadd 创建或更新它们的密钥表：每次运行它时，您都会更改密钥并破坏所有其他服务实例。您必须创建一次密钥表，然后单独分发它（例如使用 scp）。
此安全功能的操作风险非常严重，几年前我入侵了我们的 MIT KDC，将密钥提取添加到 RPC 协议中，并将其作为 ktadd 命令的默认选项。Heimdal 没有这个问题。