SQL Server通过SSH隧道连接失败的主因是端口转发配置错误或未生效；需正确设置ssh -L本地端口映射、启用目标SQL Server的TCP/IP协议与远程连接、放行防火墙、禁用WinRM冲突服务、使用SQL认证而非Windows认证、配置KeepAlive保活参数，并避免连接字符串中误设Encrypt=yes。
SQL Server 连接失败但 SSH 能通，大概率是端口没转发对
ssh 隧道连 sql server 不是“连上跳板机就行”，关键在本地端口是否真正映射到目标 sql server 的 1433（或自定义端口）。常见现象是 sqlcmd 或 ssms 报错：cannot connect to [localhost], error: 2 或 a network-related or instance-specific error...——这基本说明隧道没生效，或者 sql server 拒绝了来自隧道的连接。
实操建议：
- 用
ssh -L 1434:target-sql-server:1433 user@jump-host建立本地端口转发（注意：本地端口别选1433，避免和本机 SQL Server 冲突；这里用1434） - 确认目标 SQL Server 已启用 TCP/IP 协议（SSMS → 服务器属性 → 连接 → 勾选“允许远程连接到此服务器”；SQL Server 配置管理器 → SQL Server 网络配置 → 启用 TCP/IP）
- 检查目标服务器防火墙是否放行
1433（仅对跳板机开放即可，不对外网开放） - 连接时客户端地址填
localhost,1434（注意逗号，不是冒号），不是jump-host或目标 IP
Windows 跳板机上用 OpenSSH 做中转，得关掉 WinRM 冲突服务
Windows Server 自带的 OpenSSH Server 默认监听 22，但若系统同时启用了 WinRM（如被 Ansible 或 PowerShell Remoting 使用），可能抢占端口或干扰认证流程，导致 SSH 连接后无法稳定维持隧道。
实操建议：
- 运行
Get-Service sshd, winrm查看状态；若winrm是 Running，临时停用：Stop-Service winrm（非永久禁用，避免影响其他运维任务） - 确认
sshd_config中AllowTcpForwarding yes已启用（路径通常是C:\ProgramData\ssh\sshd_config），改完需Restart-Service sshd - 避免用 PowerShell 直接执行
ssh命令时加-f（后台运行），Windows 下容易断开；改用Start-Process或保持终端打开
SQL Server 登录失败：不是密码错，而是登录名没适配隧道上下文
走 SSH 隧道后，SQL Server 看到的客户端 IP 是跳板机的本地回环（127.0.0.1 或 ::1），不是你的真实出口 IP。如果 SQL Server 的登录策略依赖 IP 白名单、或启用了基于主机的限制（如 sys.server_principals 中绑定了特定 host），就可能拒绝连接。
实操建议：
- 优先用 SQL Server 认证（sa 或普通 SQL 用户），而非 Windows 身份验证——后者在隧道场景下会丢失域上下文，报
Login failed for user ''. The user is not associated with a trusted SQL Server connection. - 检查登录名是否被显式 deny：运行
SELECT name, type_desc, is_disabled FROM sys.server_principals WHERE name = 'your_user';，确保is_disabled = 0 - 若必须用 Windows 身份验证，需在跳板机上用
runas /netonly启动 SSMS，并指定域凭据，但这条路兼容性差、易出 Kerberos 错误，不推荐
隧道自动断开？别只怪网络不稳定，先查 KeepAlive 设置
SSH 隧道空闲几分钟后静默断开，不是跳板机配置问题，大概率是客户端或中间网络设备（如企业防火墙）主动 kill 了长连接。OpenSSH 默认不发保活包，TCP 连接会被认为“已失效”。
实操建议：
- 客户端加参数：
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -L 1434:target:1433 user@jump-host（每 60 秒发一次心跳，连续 3 次无响应才断） - 跳板机端也要配
ClientAliveInterval 60和ClientAliveCountMax 3（在/etc/ssh/sshd_config或 Windows 的sshd_config中），否则服务端先断 - 避免用
autossh类工具做自动重连——SQL Server 客户端（如sqlcmd）不感知隧道重建，会卡在旧连接上；应由应用层控制重连逻辑
最常被忽略的一点：SQL Server 的连接字符串里不能写 Encrypt=yes 除非你确认跳板机与目标之间 TLS 链路完整。隧道本身不加密 SQL Server 协议，它只是 TCP 封装。强行开启加密会导致握手失败，错误信息是 Shared Memory Provider: No process is on the other end of the pipe. ——看着像管道问题，其实是 TLS 握手卡死。
