authentication failed（错误码18或8000）主因是keyfile权限或内容不一致、system.users未同步、或auth开启早于副本集初始化；需验证keyfile可读性与sha256sum一致性、各节点credentials及roles完全匹配，并确保先初始化再启用auth。
副本集成员同步失败时出现 Authentication failed（错误码 18 或 8000），大概率不是密码输错了，而是节点间认证机制没对齐——KeyFile、用户元数据、启动时机三者只要有一处不一致，心跳就断在 auth 阶段。
KeyFile内容或权限不一致导致mongod根本起不来
节点启动时连日志都不报就挂掉，或者 rs.status() 里状态一直是 STARTUP2 或 DOWN，先查 KeyFile：
- 用
sudo -u mongod cat /etc/mongod-keyfile在每个节点上测试是否真能读；读不出就是权限问题，常见于文件属主是root但mongod进程以mongod用户运行 - KeyFile 必须字节级完全相同：用
sha256sum /etc/mongod-keyfile在所有节点比对输出，Windows 编辑器保存、echo生成、scp ASCII 模式传输都会悄悄改内容 - 文件权限必须是
400（仅所有者可读），不能有执行位；父目录也要让mongod用户有执行权（x），否则进不去目录 -
security.keyFile在mongod.conf中必须写绝对路径，不能用~/或相对路径；改完配置后必须sudo systemctl restart mongod，别只 reload
副本集初始化前就启用了auth或keyFile
这是新手最常踩的坑：配置文件一开 auth: true 或 keyFile，就直接跑 rs.initiate()，结果报 Unauthorized 或 command replSetInitiate requires authentication。
- 正确顺序是：先关掉
auth和keyFile，启动所有节点，用mongo连上去执行rs.initiate(cfg)完成初始化 - 等
rs.status()显示 PRIMARY 和 SECONDARY 都正常了，再停掉所有节点，打开auth和keyFile，重启 - 如果已经开了 auth 却还没初始化，只能临时注释掉配置里的
security块，重启 mongod，再初始化，之后再恢复配置 - Docker 场景下尤其要注意：官方镜像不会自动
rs.initiate()，哪怕你写了--replSet参数，也得进容器手动执行一次
system.users在各节点间不同步引发主切后认证失败
主节点切换后，新主能连，原主（现为从）却报 Authentication failed，但用户名密码完全没错——说明 admin.system.users 集合没同步。
- MongoDB 不复制
admin.system.users，它只靠你手动保证各节点一致；不能只查数量，要逐个比对每个用户的credentials.SCRAM-SHA-256.digest和roles数组内容（包括db字段大小写） - 别在从节点上直接
db.createUser()补用户：盐值和哈希逻辑可能因版本/环境微差，导致 credentials 不兼容 - 安全做法是用
mongodump -d admin -c system.users导出快照，再用mongorestore --drop覆盖目标节点；操作前务必停掉该节点或暂停复制（rs.pauseReplication()） - 预防的关键是把用户创建步骤写进部署脚本，而不是人工连 shell 手动建
真正难排查的从来不是“连不上”，而是“看起来连上了，但心跳被 auth 拦在门口”。KeyFile 的权限、system.users 的 digest 值、初始化与开启 auth 的先后顺序——这三点任何一个差一个字节或一步顺序，都会让整个副本集卡在认证环节，且错误日志往往只显示笼统的 Authentication failed。
