navicat ssh隧道不支持多用户共享，所谓“团队协作”实为每人独立配置密钥与账号，并统一规范主机填127.0.0.1、ssh填跳板机信息、mysql用户授权需匹配localhost或具体内网ip。
navicat 的 ssh 隧道本身不支持多用户共享连接，所谓“团队协作”必须拆解为每人独立配置 + 统一规范管理，否则必然出现权限混乱、隧道冲突或安全基线崩塌。
Navicat 里填错主机名是连不上的第一原因
很多人以为“SSH 填跳板机，MySQL 也填跳板机”，结果死活连不上。关键点只有一个：常规选项卡里的主机名/IP地址必须是 127.0.0.1 或 localhost，绝不能填服务器公网 IP 或内网数据库 IP。
- SSH 部分（
SSH选项卡）：填跳板机地址（如203.101.55.88）、端口（22）、系统用户名（如ubuntu） - MySQL 部分（
常规选项卡）：主机必须是127.0.0.1，端口填数据库真实端口（如3306），账号密码是数据库账号，不是系统账号 - 如果跳板机和数据库不在同一台机器上（比如数据库在
192.168.1.20:3306），那得用命令行先建好隧道：ssh -L 3307:192.168.1.20:3306 ubuntu@203.101.55.88，然后 Navicat 的 MySQL 主机填127.0.0.1、端口填3307
密钥认证比密码更稳，但私钥权限不对就直接拒连
Navicat 支持 .ppk（PuTTY 格式）和 OpenSSH 格式私钥，但无论哪种，本地私钥文件权限必须严格限制——Linux/macOS 下必须是 600，Windows 上则需确认 Navicat 有读取权限。
- OpenSSH 私钥权限修复命令：
chmod 600 ~/.ssh/id_rsa - PuTTY 密钥若由
puttygen生成，导出时选 “Export OpenSSH key” 更兼容；避免用旧版 PuTTY 导出的.ppk，某些 Navicat 版本会静默失败 - 别在 Navicat 配置里硬写密码——密码认证适合临时调试，团队长期使用必须走密钥 + 禁用密码登录（
PasswordAuthentication noin/etc/ssh/sshd_config）
bind-address 和 MySQL 用户 Host 必须匹配隧道逻辑
隧道本质是让流量从跳板机的 127.0.0.1 发起访问本地 MySQL，所以数据库服务必须监听回环地址，且用户授权允许从该来源连接。
- 检查 MySQL 配置：
grep bind-address /etc/mysql/mysql.conf.d/mysqld.cnf，值应为127.0.0.1（不是0.0.0.0，也不是内网 IP） - 检查用户权限：
SELECT User,Host FROM mysql.user WHERE User='your_db_user';，Host字段必须是'%'或'localhost'；如果是'192.168.1.100'这类具体 IP，就得执行：GRANT ALL ON *.* TO 'your_db_user'@'localhost' IDENTIFIED BY 'xxx'; FLUSH PRIVILEGES; - 阿里云 RDS 不适用此方案——RDS 不提供 SSH 接入，只能直连或通过云企业网+堡垒机中转
团队共用一套配置？别信，每人必须独立配密钥和账号
“统一配置发给所有人”是最大陷阱。一旦某人密钥泄露或离职，整个通道就失守。正确做法是每人生成专属密钥对，并在服务器上追加公钥到 ~/.ssh/authorized_keys，数据库侧创建对应账号并限定权限范围。
- 密钥命名建议带人名和用途，例如：
navicat_alice_prod，避免多人共用id_rsa - 数据库账号按角色最小化授权：
GRANT SELECT,INSERT ON app_log.* TO 'alice_dev'@'localhost';，禁止GRANT ALL给非 DBA 账号 - Navicat 连接名统一前缀（如
[PROD] MySQL - Alice），方便团队识别归属和环境，但配置内容绝不复用
真正难的不是配通，而是让每个人配得一致、改得及时、废得干净——密钥轮换、账号回收、配置归档，这些操作没有图形界面能自动完成，全靠团队约定和脚本兜底。
