navicat截至2026年4月不支持交互式双因子认证（2fa），无法输入totp验证码；连接启用2fa的数据库会因缺失第二因素校验而报“access denied”，需通过ssh隧道、客户端证书或绕行内网账号等方式规避。
navicat 当前（截至 2026 年 4 月）不支持通过交互式窗口输入双因子认证（2fa）验证码来完成数据库连接。
这意味着：即使你的 MySQL、PostgreSQL 或其他数据库后端已启用 TOTP（如 Google Authenticator）、SMS 或硬件密钥类的双因子验证，Navicat 的标准连接流程无法弹出输入框让你手动填入动态验证码，也不会调用系统通知或外部认证器回调。
Navicat 连接带 2FA 的数据库时实际会发生什么
- 你填写主机、端口、用户名、密码后点击“测试连接”，大概率会收到类似错误：
Access denied for user 'xxx'@'yyy' (using password: YES) - 即使密码正确，只要服务端强制要求 2FA，认证链会在密码之后再校验第二因素 —— 而
Navicat的 MySQL/PostgreSQL 驱动（基于 libmysqlclient 或 libpq）根本不传输或处理 TOTP 字段 - 官方文档和已知版本（包括
Navicat 17及最新Navicat Premium 17.1）均未提供“验证码输入框”“TOTP token 字段”或“2FA callback hook”等配置项
常见绕过方式与适用场景
-
使用 SSH 隧道 + 服务端免 2FA 的本地用户
- 在数据库服务器上创建一个仅允许
127.0.0.1访问、且不启用 2FA 的专用账号 -
Navicat通过 SSH 隧道连到本机端口（如localhost:3307），再由 SSH 转发至真实数据库（127.0.0.1:3306） - 此时认证发生在内网，可绕过面向公网的 2FA 策略
- 在数据库服务器上创建一个仅允许
-
启用 基于证书的客户端认证（如 MySQL 的 X.509）替代 2FA
- 某些部署将 2FA 逻辑下沉到 TLS 层（如用客户端证书做第二因子）
-
Navicat支持在“SSL”选项卡中加载client-cert.pem和client-key.pem，此时可跳过 TOTP 流程
-
改用支持 2FA 的 CLI 工具临时补位
- 例如 MySQL 8.0+ 原生支持
mysql --enable-cleartext-plugin+ TOTP 插件，但需配合终端交互 -
Navicat不具备该能力，不能复用同一套插件机制
- 例如 MySQL 8.0+ 原生支持
容易被忽略的关键点
- 数据库是否真启用了 2FA？很多所谓“2FA”其实是应用层网关（如 Cloudflare Access、JumpServer）做的，不是数据库原生支持 —— 此时你在
Navicat里连的是网关，而网关可能提供 Web 表单或 API Token 入口，但Navicat仍只能走传统账号密码 - PostgreSQL 的
pg_hba.conf若设为auth-method: scram-sha-256或cert，不等于开启 2FA；真正实现双因子必须搭配额外扩展（如pg_totp），而这些扩展返回的错误对Navicat来说就是“密码错”
Navicat 的协议栈止步于传统认证环节，它不会、也不能参与后续的动态令牌交换。如果你的运维策略强制要求每次连接都输验证码，那就得换工具——或者让 DBA 开个白名单内网账号。
