分片集群无法开启鉴权的根本原因是节点间内部认证未打通，即keyFile未配置或配置错误。需确保keyFile权限为600、属主正确、SELinux上下文合规；mongos不支持keyFile；客户端连接须显式指定authMechanism和authSource；副本集启用keyFile前必须清空local库并重新初始化；keyFile内容须用openssl生成纯二进制Base64字符串。
分片集群无法开启鉴权，根本原因不是配置漏了 authorization: enabled，而是节点间内部认证没打通——keyFile 没配或配错，导致整个集群启动失败或后续认证被静默拒绝。
mongod 启动时直接报错：Permissions on keyfile are too open
这是最常卡住的第一步。MongoDB 要求 keyFile 文件权限必须是 600（仅所有者可读写），且属主必须是运行 mongod 进程的用户（通常是 mongod 或 mongodb）。
- 错误示例：
chmod 644 /etc/mongod-keyfile→ 启动失败，日志明确提示权限太松 - 正确操作：
chmod 600 /etc/mongod-keyfile && chown mongod:mongod /etc/mongod-keyfile - SELinux 环境下还需补一句：
chcon -t mongod_var_lib_t /etc/mongod-keyfile，否则即使权限对也过不了安全上下文校验
mongos 启动失败：Failed to load configuration from file
很多人把 security.keyFile 错误地加到 mongos.conf 里，但 mongos 不支持该配置项。它不参与数据存储和副本集同步，只做路由转发，因此不需要、也不能配置 keyFile。
- 现象：改完配置后
mongos直接无法启动，日志只报配置加载失败，不提具体哪行错 - 检查点：确认
mongos.conf中security:下没有任何keyFile字段；只有mongod（shard 和 config server）才需要 - 混淆来源：误以为“所有集群节点都要 keyFile”，其实
mongos是个例外
能连上 mongos，但查不到数据：Authentication failed 或 not authorized on admin
这说明内部通信（shard ↔ config server）可能通了，但客户端连接没走对认证路径。关键点在于：启用 keyFile 后，authorization: enabled 自动生效，但客户端连接必须显式声明机制和认证库。
- 常见错误连接串：
mongodb://user:pass@host:27017/db→ 缺少authMechanism和authenticationDatabase - 正确写法：
mongodb://user:pass@host:27017/db?authMechanism=SCRAM-SHA-256&authSource=admin - 用
mongosh连 replica set 或 config server 时，必须加参数：mongosh --username admin --password xxx --authenticationDatabase admin - 注意：
authSource不是随便选的数据库，必须是创建该用户的库（通常是admin）
副本集成员反复初始化失败：Unable to authenticate using sasl protocol
这不是网络不通，而是节点之间握手阶段就失败了。一旦某个 mongod 实例曾以非认证模式启动过，再加 keyFile 就会彻底拒绝加入集群——MongoDB 不支持“热升级”内部认证。
- 典型场景：先搭好副本集跑了一周，再回头加
keyFile→ 所有节点日志刷Unable to authenticate using sasl protocol - 唯一解法：停掉全部节点，清空
dbPath下的local.*文件（或整个local数据库），重新初始化副本集 - 预防建议：keyFile 必须在首次启动前就配置好；生产环境建议用
x.509替代，它支持证书轮换而不中断服务
最容易被忽略的一点：keyFile 内容不能含换行、不能是明文密码、不能用 echo "abc" > file 生成。必须用 openssl rand -base64 756 > /etc/mongod-keyfile 这类方式生成纯二进制 Base64 字符串——少一个字节、多一个回车，都会让整个集群拒绝握手。
