Ssh

在企业网络环境中，通过跳板机访问内网或 WSL2 主机时，SSH 经常出现不稳定问题，例如连接卡在 SSH2_MSG_KEX_ECDH_REPLY，或在连接成功后出现 vim/tmux 显示不完整、会话假死等现象。 这类问题本质上与网络路径、MTU、TCP 长连接稳定性有关，单纯依赖 ssh 或 autossh 很难彻底解决。 目标 实现如下访问路径： MacBook → 公网服务器 → 内网机器 / WSL2 在 MacBook 上通过 SSH 连接公网服务器的某个端口，即可稳定访问内网主机的 SSH 服务。 服务端（公网服务器） 下载并启动 frps： wget https://github.com/fatedier/frp/releases/download/v0.53.2/frp_0.53.2_linux_amd64.tar.gz tar xf frp_0.53.2_linux_amd64.tar.gz cd frp_0.53.2_linux_amd64 创建最小配置： # frps.ini [common] bind_port = 7000 启动服务： ./frps -c frps.ini 确保云防火墙放行 7000 端口。 客户端（内网机器 / WSL2） 下载 frpc 并配置反向 SSH 通道： wget https://github.com/fatedier/frp/releases/download/v0.53.2/frp_0.53.2_linux_amd64.tar.gz tar xf frp_0.53.2_linux_amd64.tar.gz cd frp_0.53.2_linux_amd64 # frpc.ini [common] server_addr = 公网服务器IP server_port = 7000 [ssh] type = tcp local_ip = 127.0.0.1 local_port = 22 remote_port = 2222 启动客户端： ...

在 WSL2（Ubuntu 22.04） 中，通过 ssh 连接远端服务器时，连接会无响应。执行调试命令： ssh -vvv user@host 可以看到输出停在： expecting SSH2_MSG_KEX_ECDH_REPLY 客户端不再继续，服务器侧也没有任何日志。更换网络或在 Windows 原生终端中连接正常，说明并非服务器或账号问题。 搜索该现象后，定位到 Unix StackExchange 上的一篇帖子，指出这是 SSH 在 密钥交换阶段（KEX） 发送的握手包过大，在某些网络（WSL2 NAT、防火墙、VPN、校园/公司网络）中触发 Path MTU 黑洞，导致服务器无法收到 KEX_ECDH_INIT，因此不会返回 SSH2_MSG_KEX_ECDH_REPLY。 按照帖子中的建议，手动指定较短的密钥交换算法测试： ssh -o KexAlgorithms=ecdh-sha2-nistp521 user@host 连接立即成功，确认问题与网络路径和握手包大小有关。 为避免每次手动指定参数，将配置写入用户级 SSH 配置文件： ~/.ssh/config 内容如下： Host my-server HostName real.server.ip.or.domain User myuser KexAlgorithms ecdh-sha2-nistp521 此后使用 ssh my-server 即可正常连接，问题稳定解决。