mongos无法解析Kerberos realm或找不到有效密钥表时，客户端连接在SASL/GSSAPI协商阶段直接失败；需检查mongos是否通过security.kerberos.keyFile显式指定可读的、含匹配FQDN服务主体的独立.keytab文件，并确保连接字符串中authMechanism=GSSAPI、authSource=$external且主机名全程使用一致FQDN。
mongos 无法解析 Kerberos realm 或找不到有效密钥表时，客户端连接会直接失败——这不是密码错误，而是身份验证流程在 SASL/GSSAPI 协商阶段就中断了。
检查 mongos 启动时是否加载了正确的密钥表文件
mongos 必须显式通过
--keyFile（注意：不是
--kerberosKeyTab）或配置文件中的
security.kerberos.keyFile 指向有效的密钥表（.keytab），且该文件需满足：
- 路径对
mongos 进程用户可读（常见坑：root 创建，mongod 用户无权限）
- 密钥表中必须包含与
mongos 实例 FQDN 匹配的服务主体，例如 mongodb/mongos01.example.com@EXAMPLE.COM
- 不能复用副本集成员的密钥表——分片集群中每个
mongos 都需独立注册服务主体并生成对应密钥表
若启动时报错
Failed to initialize GSSAPI: Unspecified GSS failure，大概率是密钥表路径错误或主体不匹配。
确认连接字符串中指定了正确的 authMechanism 和 authSource
Kerberos 要求显式声明认证机制和源数据库：
-
authMechanism=GSSAPI 是强制项，不可省略或拼错
-
authSource=$external 必须设置，因为 Kerberos 用户不存于任何本地数据库，而是在外部 KDC 中管理
- 用户名必须是完整的主体名（如
user@EXAMPLE.COM），不能只写 user
错误示例：
mongodb://user@mongos01:27017/?authMechanism=SCRAM-SHA-256 —— 这会跳过 Kerberos，走本地用户校验并失败。
验证 DNS 和 FQDN 解析是否一致
Kerberos 对主机名极其敏感：
-
mongos 启动参数、密钥表中的服务主体、客户端连接字符串里的 host，三者必须使用**完全相同的 FQDN**（如 mongos01.example.com），不能混用 IP、短名或别名
-
nslookup mongos01.example.com 和 host mongos01.example.com 必须返回一致的 A 记录；反向 DNS（PTR）也建议配置，部分 Kerberos 实现会校验
- 若用负载均衡 VIP 接入，客户端连接字符串中的 host 必须仍是后端
mongos 的 FQDN，而非 VIP 名——GSSAPI 协商发生在 TCP 层之上，不感知 VIP
抓包确认 GSSAPI 协商是否真正发起
当其他检查都看似正常但仍失败时，最直接的方式是抓包：
- 在客户端机器运行
tcpdump -i any port 27017 -w kerb.pcap
- 执行连接命令（如
mongo --username user@EXAMPLE.COM --authenticationMechanism GSSAPI --host mongos01.example.com）
- 用 Wireshark 打开
kerb.pcap，过滤 gss-api，看是否有 AP-REQ 流量发出
如果没有
AP-REQ，说明客户端根本没进入 Kerberos 流程——通常是驱动不支持（如旧版 Node.js MongoDB Driver）、环境缺少
krb5-user 包，或连接字符串漏了
authMechanism。
FQDN 不一致和密钥表权限问题占 Kerberos 连接失败的七成以上，但它们往往不报具体错误，只显示模糊的
Authentication failed。调试时优先盯死这两点，比反复检查 KDC 配置更高效。
