AWS上MongoDB集群新增节点遇AuthenticationFailed问题排查

你大概率是搞混了MongoDB的客户端用户认证和集群节点间内部认证这两个完全独立的配置，这是新手玩MongoDB集群时很容易踩的坑！

1. 节点间内部认证才是这次报错的核心 #

你注释了clusterAuthMode和keyFile，但现有集群的其他节点应该还是启用了基于keyFile的内部认证机制。当新节点尝试加入集群时，集群里的老节点会要求新节点提供合法的keyFile来验证身份——这和你禁用的authorization（客户端用户登录认证）根本不是一回事！新节点没配置正确的keyFile，自然会被老节点拒绝，抛出认证失败的错误。

解决步骤：

• 把mongod.conf里的clusterAuthMode和keyFile配置取消注释，确保新节点使用的keyFile和现有集群节点的完全一致（文件内容要一模一样，而且文件权限必须设为600，所有者要和运行mongod的用户一致）
• 重启新节点的mongod服务，再尝试执行加入集群的命令

2. 关于AWS默认用户的疑问 #

如果你是在EC2上自行部署的MongoDB集群，AWS不会自动创建任何MongoDB用户（包括所谓的主用户名和密码），所有用户都需要你手动在数据库里创建。但如果是用AWS Marketplace的MongoDB镜像部署的，部分第三方镜像可能会预设默认用户，你可以去镜像的官方文档里查，或者看mongod的初始启动日志确认。

3. 额外排查小技巧 #

• 看新节点的mongod日志：默认路径一般是/var/log/mongodb/mongod.log，里面会有更详细的报错细节，能帮你精准定位是节点间认证问题还是客户端用户的问题
• 管理员用户权限检查：之后如果要重新启用客户端认证，记得确保你创建的管理员用户是在admin数据库下创建的，并且拥有root或者clusterAdmin这类集群管理相关的角色
• 二次确认SSL配置：虽然你说SSL没问题，但还是要检查新节点的SSL证书、私钥路径和老节点完全匹配，毕竟SSL配置错误有时候也会伪装成认证失败的报错

内容的提问来源于stack exchange，提问作者Amit