通过SSH隧道用DBeaver JDBC连接Redshift仅Mac端可用问题排查

这是DBeaver跨平台默认配置不一致导致的典型连通性问题，按以下优先级排查即可解决：

• 优先检查SSH实现组件是否匹配
  22.1.0版本DBeaver在不同安装渠道下的SSH隧道默认实现不一致：Brew安装的Mac版默认启用SSHJ组件，而Chocolatey分发的Windows版默认使用老旧的JSch组件。JSch对新版OpenSSH格式私钥（带BEGIN OPENSSH PRIVATE KEY头的ed25519密钥、带bcrypt加密的RSA密钥）兼容性极差，认证阶段卡住无明确报错，最终表现为连接超时。
  操作路径：打开对应Redshift连接的SSH隧道配置页，拉到高级设置区域，将SSH实现从默认的JSch手动切换为SSHJ，保存后重新测试连接。
• 排查私钥文件的隐性格式/路径问题
  即使密钥内容完全一致，Windows环境下两类隐性问题会导致密钥读取失败：
  1. 私钥存放路径包含中文、空格、特殊字符（比如中文用户名目录下的.ssh文件夹）
  2. 私钥文件被Windows记事本类工具修改过，换行符变为Windows格式的CRLF、或文件带UTF-8 BOM头，Java生态的SSH组件无法正常解析
     解决方式：将私钥放到纯英文无空格的路径下（例如C:\ssh-key\bastion.pem），用纯文本编辑器将文件换行符转为Unix LF格式、编码设为无BOM的UTF-8，重新在DBeaver中加载该私钥。
• 排查本地端口占用与代理拦截问题
  1. 本地监听端口冲突：Windows下如果配置的本地转发端口（默认常用5439）被残留进程、其他服务占用，DBeaver隧道绑定端口失败时不会抛出明确错误，会直接提示超时。可在命令提示符执行netstat -ano | findstr :你配置的本地转发端口，若存在占用进程可更换为15439这类未被使用的端口重试。
  2. 代理/安全软件拦截：Windows下全局代理、VPN的TUN模式可能劫持Java程序的出站流量，或打乱localhost路由规则导致隧道建立失败。可临时关闭系统代理、第三方安全工具测试；若需保留代理，可在DBeaver首选项的「网络连接」配置中，将SSH连接的代理规则设为直连或与系统代理匹配。
• 快速定界验证方法
  可先跳过DBeaver自带的隧道功能，用Windows原生OpenSSH手动建立隧道验证网络与密钥有效性：

  ssh -i 你的私钥完整路径 -L 15439:<你的Redshift集群端点>:5439 <堡垒机登录用户>@<堡垒机公网IP> -N
  

  执行后不要关闭命令窗口，直接在DBeaver中新建直连localhost:15439的Redshift连接，若能正常连通，即可确认问题完全出在DBeaver自带SSH隧道的配置上，和网络、防火墙、堡垒机/Redshift侧的安全组配置无关。

内容的提问来源于stack exchange，提问作者jmkite