Navicat连接MongoDB身份验证失败配置SCRAM-SHA-1协议解决
Navicat连接MongoDB报身份验证失败,因低版本不兼容MongoDB6 0后默认的SCRAM-SHA-256。需服务端禁用SHA-256并启用SHA-1,重建用户指定SCRAM-SHA-1,正确填写认证数据库。该方案存在合规风险。
在使用 Na vicat 连接 MongoDB 时,如果遇到了 authentication failed 错误,并且已经确认用户名、密码以及认证数据库均设置正确,那么问题大概率出在 SCRAM-SHA-256 协议与 Na vicat 版本不兼容上。此时最直接有效的解决方法是强制将 MongoDB 服务端的认证协议降级为 SCRAM-SHA-1——但请注意,这项操作必须在服务端配置中完成,仅修改客户端选项是无法生效的。

为什么必须修改 mongod.conf 配置文件?
MongoDB 从 4.0 版本开始支持 SCRAM-SHA-1,但从 6.0 版本起,系统默认强制启用 SCRAM-SHA-256,而且不再允许客户端通过协商方式降级。而 Na vicat ≤16.0.17 版本无法解析 SHA-256 的挑战响应,因此连接时直接被服务端拒绝,错误信息中不会明确指出机制不匹配,只会笼统地报出 Authentication failed。
关键点在于:这不是 Na vicat 的“选项”可以调整的,必须让 MongoDB 主动使用 SHA-1 签发凭证。
- 修改
/etc/mongod.conf(Linux)或mongod.cfg(Windows),在security部分添加如下配置:
security:
authorization: enabled
sasl:
hostName: your-hostname # 可选,若出现 SASL 错误再增加
serviceName: mongodb # 强制使用 SHA-1 认证机制
enableLocalhostAuthBypass: false
- 在
setParameter区块中显式指定(适用于 MongoDB ≥4.2):
setParameter: scramIterationCount: 10000 # 关键:禁用 SHA-256,仅保留 SHA-1 disableScramSHA256: true
- 保存文件后重启服务:
sudo systemctl restart mongod(Linux)或net stop MongoDB && net start MongoDB(Windows)
用户必须使用 SCRAM-SHA-1 方式重新创建
即使密码没有改变,只要用户是在 SHA-256 启用状态下创建的,存储的凭证哈希就是 SHA-256 格式。服务端降级配置后,原有的用户仍然无法识别,只能删除后重新创建。
- 先删除原用户(以
admin库为例):
use admin
db.dropUser("myuser")
- 再创建新用户,并明确指定认证机制(MongoDB 4.0+ 支持):
db.createUser({
user: "myuser",
pwd: "mypass",
roles: [{ role: "readWrite", db: "myapp" }],
mechanisms: ["SCRAM-SHA-1"] // 必须添加此行
})
- 验证配置是否生效:执行
db.getUser("myuser"),返回结果中应包含"mechanisms" : ["SCRAM-SHA-1"]
Na vicat 连接配置中“Authentication Database”字段不能留空
即使服务端已启用 SCRAM-SHA-1,如果 Na vicat 的 Authentication Database 字段为空或填写错误,仍然会报错。MongoDB 不会自动回退到 admin 库。
- 该字段值必须与用户创建时所在的数据库完全一致,注意大小写敏感
- 管理员用户一定是在
admin库创建的,因此此处必须填写admin - 普通业务用户若在
myapp库创建,则此处应填写myapp,而不是admin - Na vicat for MongoDB v16.0.17 及更早版本没有“认证机制”下拉菜单,它只识别 SHA-1 —— 因此只要服务端配置正确,客户端自然就能正常工作
此方案的代价与边界
启用 disableScramSHA256: true 后,所有新用户只能使用 SHA-1;已有的 SHA-256 用户会失效,必须重建。SHA-1 虽然仍被 MongoDB 官方支持,但 NIST 已建议弃用,长期在生产环境中使用存在合规风险。
真正彻底的解决方案是升级 Na vicat 到 v17 以上版本,这些版本原生支持 SHA-256。但如果受限于许可证或内部策略无法升级,那么服务端强制使用 SHA-1 就是改动范围最小、成功率最高的实践路径——不过请记住,每次新建用户都必须显式添加 mechanisms: ["SCRAM-SHA-1"],一旦遗漏就会再次无法连接。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
SQL中HAVING子句性能有时优于WHERE子句的深度原因解析
先抛个结论,帮大家省点纠结的时间:HA VING 真的从来就不比 WHERE 性能更好。江湖上流传的“HA VING 更快”,大多是拿错了对比样本,或者是被缓存、数据量这些小细节晃了一下眼。问题的根源其实就一句话:混淆了“执行阶段”和“数据量”这两个完全不同的概念。把它们的先后顺序和各自能干的事儿理
SQL开窗函数计算分组内占比的详细教程
开窗函数这个话题,其实最核心的价值就在于它能让我们在保留全部明细数据的同时,完成复杂的聚合计算。比如,要算每个产品在其所在分类中的销售占比,这在报表分析里太常用了。如果用传统GROUP BY再加JOIN回去,SQL写得啰嗦不说,性能也糟糕。 计算分组内占比的核心逻辑 说白了就是:用当前行的值,除以它
移动端App接口Token未校验导致SQL注入的解决方案
先纠正一个常见误解:Token未校验本身并不会直接导致SQL注入——它只是一个身份凭证,不是SQL的输入源。真正的问题出在另外一条链路上:攻击者利用未校验的Token轻松绕过鉴权,然后塞进恶意参数(比如 user_id、keyword),这些参数再被拼接到SQL中执行,这才是灾难的开端。 所以修复的
Navicat还原后中文字符显示问号的解决方法
说实话,遇到Navicat还原后中文字符全部变成问号的情况,大多数用户的第一反应往往是备份文件损坏了。但真相其实很简单——问题不在文件本身,而是Navicat在还原过程中跳过了字符集协商环节,直接将utf8mb4的字节按照latin1或gbk编码“硬解”写入。换句话说,它根本没有询问数据库“你使用的
Redis集群从节点频繁掉线检查MTU与心跳包大小
揭示一个容易被忽视的问题:Redis集群中从节点频繁掉线,绝大多数情况并非配置错误,而是网络层默默出现丢包——尤其是MTU参数不匹配时,心跳包被迫分片甚至直接被截断。 先说核心判断:MTU不一致确实会导致Redis从节点掉线,这听起来有些反直觉,但却是真实的线上踩坑经验。心跳包(PING PONG)
- 热门数据榜
相关攻略
2026-07-11 07:02
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
2026-07-11 07:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程

