MySQL Workbench 本身不提供“开启SSH”功能，仅支持通过已建立的SSH隧道连接MySQL；其Standard TCP/IP over SSH模式可自动完成SSH端口转发，无需额外安装PuTTY或手动执行ssh命令，但要求远程MySQL监听127.0.0.1:3306且用户权限匹配'username'@'127.0.0.1'。
MySQL Workbench 本身不提供“开启SSH”的功能，它只支持通过已建立的 SSH 隧道连接 MySQL。真正起作用的是 SSH 协议层的端口转发，Workbench 只是把本地某个端口（比如 3307）当作目标 MySQL 实例来连——背后流量全由 SSH 隧道加密中转。
MySQL Workbench 里选 Standard TCP/IP over SSH 就够了
不用额外装 PuTTY 或手敲 ssh -L 命令，Workbench 内置支持完整隧道流程：
- 新建 Connection → Connection Method 下拉选
Standard TCP/IP over SSH -
SSH Hostname填跳板机或目标服务器 IP（如192.168.1.100），不是 MySQL 的地址 -
SSH Username和SSH Password（或SSH Key File）必须能成功登录该主机 -
MySQL Hostname填127.0.0.1（不是localhost），因为隧道打通后，MySQL 看到的是本机回环的 TCP 连接 -
MySQL Server Port填远程 MySQL 实际监听的端口（通常是3306），不是你本地开的端口
Workbench 会在连接时自动启动一个后台 SSH 进程做端口转发，断开连接时自动清理。不需要手动保活、也不用担心 PuTTY 窗口关闭导致中断。
远程 MySQL 必须监听 127.0.0.1:3306 且允许该来源用户
很多人卡在“测试连接失败”，但 SSH 登录明明成功了——问题几乎都出在 MySQL 侧配置：
- 检查远程 MySQL 是否真在监听：运行
netstat -tlnp | grep :3306，输出里要有127.0.0.1:3306或*:3306，不能只有127.0.0.1:3306且是tcp6（IPv4 客户端连不上） - 确认
bind_address没设成127.0.0.1（这会让 MySQL 拒绝所有外部 TCP 连接），应设为0.0.0.0或留空，并靠防火墙/SSH 限制访问来源 - 用户权限必须匹配连接来源地址：Workbench 经隧道连过去，MySQL 收到的是来自
127.0.0.1的连接，所以得有'myuser'@'127.0.0.1'，不是'myuser'@'localhost'（走 socket）也不是'myuser'@'%'（不安全）
本地端口冲突或被绑定限制时会静默失败
Workbench 默认用随机本地端口做转发，但如果你手动指定或环境受限，容易踩坑：
- 别用
3306作为本地转发端口——如果本机也跑 MySQL，会冲突；Workbench 可能不报错，但测试连接一直卡住或提示 “Connection refused” - Windows 上若用旧版 PuTTY 手动建隧道，没勾选
Local ports accept connections from other hosts，Workbench 就连不上这个端口（默认只绑127.0.0.1，但某些版本解析异常） - macOS / Linux 用命令行建隧道时，
ssh -L 3307:127.0.0.1:3306中的127.0.0.1不能写成localhost，部分 OpenSSH 版本不识别后者作目标地址
最易被忽略的一点：Workbench 的 SSH 隧道只在“测试连接”或“打开连接”时激活，关掉连接窗口后隧道就断了。如果要长期保持，得靠后台常驻的 ssh -fN 进程，而不是依赖 Workbench 自身——它不是隧道管理器，只是个客户端。
