☰

奇怪的 SSH 问题 - 单个主机不允许我通过名称登录

tag-icon • tag-icon networking domain-name-system ssh public-key
奇怪的 SSH 问题 - 单个主机不允许我通过名称登录

有人能解释一下吗，因为我已经完成了所有操作，从重新生成密钥，到“离开”并重新加入域（Centrify），而我似乎无法通过单个客户端访问 SSH 主机。除一个客户端外，所有其他客户端都可以访问此主机。但奇怪的是，如果我使用 IP 地址，我可以从客户端通过 SSH 连接到主机：

$ ssh ddecker@host
Connection closed by 10.0.0.250
$ ssh [email protected]
Password:
[ddecker@host ~]$

我唯一拥有的东西是在主机上的 /var/log/messages 中，当我尝试使用主机名时，我得到以下信息：

fatal: accept_ctx died [preauth]

我尝试删除 /etc/krb5.keytab，但 Centrify 无法启动；所以我将其恢复了。真的不知道为什么所有其他客户端都可以通过名称连接，而这是因为客户端只能通过 IP 连接。

更新 #1：

以下是输出ssh -v ddecker@host：

debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to host [10.0.0.250] port 22.
debug1: Connection established.
debug1: identity file /home/ddecker/.ssh/id_rsa type 1
debug1: identity file /home/ddecker/.ssh/id_rsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_dsa type -1
debug1: identity file /home/ddecker/.ssh/id_dsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Doing group exchange

debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Connection closed by 10.0.0.250

答案1

调试 AD/Kerberos Centrify 总是很烦人。

您可能想要尝试使用 在您的服务器上启用 Centrify 调试/usr/share/centrifydc/bin/addebug on。请注意，这可能会创建非常大的日志文件，并且如果启用时间过长可能会导致卷满。

检查 SPN 和 KVNO

从服务器上的本地密钥表获取原则和 KVNO 列表。这可能要求在 Linux 服务器上安装 Kerberos 客户端实用程序 RPM 包（yum install krb5-workstation）。

klist -kte

将其与您的 AD 确定的 Kerberos KVNO 进行比较。从另一个 Centrify enebales Linux 系统：（需要使用“kinit”启动活动的 Kerberos 登录会话，检查klist您是否拥有有效的 kerberos 票证授予票证））最好从另一台主机执行此操作，而不是从出现问题的主机执行。SSH 使用主机主体。

kvno host/hostname
kvno host/hostname.domain.name

如果上述两个命令返回的 KVNO 与使用 klist 找到的 KVNO 不同，则通常 UNIX 服务器上的本地 keytab 文件需要重置。当本地 keytab 与 AD 中的 KDC 不同步时，重置本地 keytab 是从相关主机的命令行完成的，并且需要 root 权限。

adkeytab -r -u <username>

或者使用本地计算机帐户凭据，而不是上面的特权 AD 用户

adkeytab -r -m

答案2

这些症状表明某个客户端的 kerberos 已损坏。如果您通过 IP 进行 ssh，则通常不涉及 kerberos。

一个客户端的 Kerberos 中断的最常见原因是该客户端上的时间不同步。Kerberos 要求所有相关主机的系统时钟大致同步。

/bin/date

客户端和服务器上的时间应该在几秒之内。

答案3

所以感谢大家给了我一些建议。然而，我最终找到了问题所在。我写了一个简单的 expect 脚本，基本上将我的 SSH 密钥复制到每台服务器上，它通过一个简单的文件知道服务器是什么。

因此，我没有发现任何错误，但对于这台主机，似乎我的“known_hosts”条目与我的 SSH 密钥相冲突，它基本上会断开我的连接。我删除了 known_hosts 文件（我真正要做的就是删除 known_hosts 中的一个项目），然后重试我的连接 - 并被授予访问权限。

简单的修复，但错误没有帮助我或指出明显的修复方法。

谢谢！

相关内容