SSH隧道连接MS SQL Server：PuTTY可用但OpenSSH命令行无法连通

云原生阿岚

2026-4-23

我遇到过类似的问题，PuTTY和OpenSSH在端口转发的细节处理上确实有些差异，结合你的情况，给你几个排查方向：

明确指定本地绑定地址，避免回环限制
OpenSSH for Windows默认情况下，-L参数绑定的是127.0.0.1（仅允许本地回环访问），而PuTTY默认可能允许其他本地IP访问，或者你的SQL客户端可能尝试通过本地网卡IP而非127.0.0.1连接。试试修改命令，强制绑定所有本地地址：
```
ssh -i ecdsa_id -L 0.0.0.0:1433:192.168.1.22:1433 user@remote
```
或者明确指定回环地址，确保客户端连接127.0.0.1:1433而非其他本地IP：
```
ssh -i ecdsa_id -L 127.0.0.1:1433:192.168.1.22:1433 user@remote
```
更换本地端口，避开潜在占用
Windows上如果本地安装了SQL Server服务，默认会占用1433端口，即使你没启动服务，也可能有残留的端口绑定。PuTTY可能在端口绑定上有更宽松的处理？试试换一个本地端口，比如1434：
```
ssh -i ecdsa_id -L 1434:192.168.1.22:1433 user@remote
```
然后在SQL客户端里连接127.0.0.1:1434，看看能不能连通。
开启OpenSSH客户端调试日志，排查问题
加上-v参数运行命令，查看客户端的详细日志，能帮你定位到转发是否正常、有没有连接被拒绝的细节：
```
ssh -v -i ecdsa_id -L 1433:192.168.1.22:1433 user@remote
```
重点看关于local forwarding的日志条目，确认端口是否成功绑定，以及当你尝试连接SQL Server时有没有对应的转发请求记录。
强制使用IPv4连接
有时候Windows上的OpenSSH会优先使用IPv6，而你的SQL客户端可能用的是IPv4，导致转发不匹配。试试添加-4参数强制用IPv4：
```
ssh -4 -i ecdsa_id -L 1433:192.168.1.22:1433 user@remote
```
检查Windows防火墙规则
确认本地Windows防火墙没有阻止OpenSSH的端口转发，或者阻止了SQL客户端访问1433端口。可以临时关闭防火墙测试，如果能连通，再给OpenSSH添加对应的入站/出站规则。