不能直接复制.ncx文件给同事，因其明文存密码、含绝对路径及本地状态，换设备后私钥路径失效、主机/IP不通、用户名违规；须统一SSH主机域名、端口、用户名、数据库主机（强制127.0.0.1）、MySQL授权范围，并规范私钥管理与基础设施配置。
团队专用的SSH隧道连接不是靠“共享一个Navicat配置文件”实现的，而是靠统一规范 + 可复用参数 + 权限隔离来落地。Navicat本身不提供配置版本管理或团队同步机制，硬共享ncx文件极易引发主机/端口/密钥错乱，反而导致连不上。
为什么不能直接复制.ncx连接文件给同事
Navicat的连接配置文件（.ncx）里明文存储密码（即使勾选了“保存密码”），且路径、私钥位置、本地端口映射等都是绝对路径或客户端本地状态。你电脑上能用的.ncx，换到同事机器上大概率：私钥路径不存在、数据库主机填成了192.168.x.x（他那边不通）、SSH用户名写成root但团队规定只能用deploy。
团队必须统一的关键参数项
这些字段不能由个人随意填写，需在内部Wiki或配置表中固化：
-
SSH 主机：统一使用跳板机域名（如jump-prod.example.com），禁用IP——避免云服务器IP变更后集体失效 -
SSH 端口：明确是否为非标端口（如2222），并在防火墙策略中备案 -
SSH 用户名：限定为团队预创建的系统账号（如dbtunnel），禁止使用root或个人账号 -
数据库主机：强制填写127.0.0.1（哪怕数据库在另一台内网机上）——这是隧道转发的语义前提，填localhost会走socket，填内网IP则绕过隧道 -
MySQL 用户授权范围：必须是'appuser'@'10.10.5.%'这类子网格式，而非'%'或'localhost'，否则隧道连通后仍报Access denied for user
私钥怎么管才不踩坑
团队共用同一把私钥风险极高，推荐两种安全做法：
- 每人生成自己的SSH密钥对，统一上传公钥到跳板机的
~dbtunnel/.ssh/authorized_keys，Navicat中各自填自己的.ppk（Windows）或id_rsa（macOS/Linux）路径 - 若必须共用一把密钥，私钥文件不能存桌面或下载目录；应放在团队约定的只读网络路径（如
\teamsharessh-keysprod-jump.ppk），并设置NTFS/ACL权限仅允许DBA组读取 - Navicat for Windows不认OpenSSH原生
id_rsa，必须用PuTTYgen转成.ppk；macOS/Linux版可直读id_rsa，但需确保chmod 600
连接超时或卡死？先查中间链路再动Navicat
团队环境里最常被忽略的是基础设施层限制：
- 检查跳板机
/etc/ssh/sshd_config中AllowTcpForwarding是否为yes（设为no会导致Navicat隧道建立失败，但普通SSH登录仍正常） - 确认云厂商安全组/防火墙放行了从跳板机到数据库的内网流量（例如从
10.10.5.100→10.10.5.200:3306），这个规则和SSH端口放行是两回事 - 闲置断连问题（2–3分钟无操作就Lost connection）大概率是NAT设备回收连接，需在Navicat连接属性→
高级页勾选保持连接活跃，并设每30秒发送一次心跳包
真正难的不是填对那几个框，而是让所有人理解：SSH隧道里有两层身份、两个网络视角、三套权限体系。填错任意一层，错误现象都一样——连不上，但原因天差地别。
