Kerberos:子域中的服务器上 ssh 服务器登录的主体/领域错误

Kerberos:子域中的服务器上 ssh 服务器登录的主体/领域错误

我目前尝试在位于子域“sub.example.com”中的服务器上设置 kerberos 身份验证。KDC 管理 EXAMPLE.COM,DNS 服务器管理“example.com”。由于组织原因,我们为一些服务器(server1.sub.example.com)设置了子域“sub.example.com”。此子域由单独的 DNS 服务器管理。在此服务器上,使用以下文件通过 pam 进行 Kerberos 登录可以正常工作/etc/krb5.conf

includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
[libdefaults]
        default_realm = EXAMPLE.COM
        clockskew = 300
        ticket_lifetime = 2days
        renew_lifetime = 365days
        renewable = true
        forwardable = true

[realms]
        EXAMPLE.COM = {
                kdc = kerberos.example.com
        }

如果我现在使用 Kerberized ssh 连接启用的 Kerberos,我会得到

$ssh -vvv server1.sub.example.com
...
debug1: Unspecified GSS failure.  Minor code may provide more information
Server krbtgt/[email protected] not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information
Server krbtgt/[email protected] not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information


debug3: send packet: type 50
...

并返回密码登录。我如何说服子域内的服务器使用 kerberos/ssh而不是。krbtgt/[email protected]krbtgt/[email protected]

答案1

可以尝试在 /etc/krb5.conf 中添加:

[domain_realm]
 example.com  = EXAMPLE.COM
 .example.com = EXAMPLE.COM

嗯。我觉得这肯定有效。也许可以试试:

[domain_realm]
  example.com  = EXAMPLE.COM
 .example.com  = EXAMPLE.COM
 sub.example.com = EXAMPLE.COM
.sub.example.com = EXAMPLE.COM

好吧,我能想到的办法就这么多。希望有更了解的人能来。

答案2

对我有用的解决方案

我也遇到过这个问题,这就是我解决问题的方法。

我创建了一个~/.k5identity文件本文档仅包含以下两行:

[email protected]    realm=SUB.EXAMPLE.COM
[email protected]    host=*.sub.example.com

故障排除

据我所知,该问题是由于 OpenSSH 客户端ccselect模块使用错误的方法为本次身份验证选择凭据缓存而导致的。

如果没有上述~/.k5identity文件,我在对 ssh 命令中的 kerberos 位进行故障排除时会看到如下内容:

$ KRB5_TRACE=/dev/stderr ssh -Mvvvv server.sub.example.com uptime |& less

(...)
ccselect module hostname chose cache KCM:1003 with client principal [email protected] for server principal host/[email protected]
(...)

请注意,ssh 的 ccselect 插件会自动从我的凭证缓存中选择现有凭证,并且它使用错误的领域名称执行此操作。这就是为什么 ssh 最终询问的是而不是。Server krbtgt/[email protected]Server krbtgt/[email protected]

根据上述内容~/.k5identity,以下是 kerberos-tracing ssh 命令显示的内容:

(...)
ccselect module k5identity chose cache KCM:1003:77967 with client principal [email protected] for server principal host/[email protected]
(...)

从那时起,ssh 只会尝试正确的领域 (SUB.EXAMPLE.COM)。

相关内容