Go开发SSH客户端连接AWS EC2时握手超时（命令行可正常登录）

首先明确报错本质：这个超时是TCP连接建立成功后，SSH握手阶段读取对端响应时的超时，和PEM密钥配置、认证逻辑无关（如果是密钥问题会直接返回ssh: unable to authenticate类报错），结合命令行ssh可以正常连接的前提，可从以下方向定位问题：

• 网络出口与安全组匹配问题
  AWS安全组是基于源IP地址放通22端口的，需确认运行Go代码的进程网络出口IP，和你执行命令行ssh的出口IP完全一致。如果跑Go代码时走了代理、容器网络、WSL虚拟网卡，导致出口IP变更，不在安全组允许列表内，EC2侧会直接静默丢弃来自陌生IP的SSH握手包，不会返回任何响应，最终触发读超时。
• SSH算法协商不匹配
  golang.org/x/crypto/ssh库默认支持的密钥交换算法、加密算法集合，和EC2实例上OpenSSH的默认配置存在版本差异时，部分场景不会直接返回算法协商失败，而是卡在握手等待阶段直至超时。可以在执行命令行ssh时加-v参数打印握手时使用的算法列表，将这些算法显式配置到SSH客户端参数中，示例代码段：

  config := &ssh.ClientConfig{
      User: "ec2-user",
      Auth: []ssh.AuthMethod{publicKey("mykey")},
      Timeout: 15 * time.Second,
      HostKeyCallback: ssh.InsecureIgnoreHostKey(),
      // 显式补充兼容算法
      Config: ssh.Config{
          KeyExchanges: []string{
              "curve25519-sha256@libssh.org",
              "ecdh-sha2-nistp256",
              "diffie-hellman-group14-sha256",
          },
          Ciphers: []string{
              "aes128-ctr",
              "aes192-ctr",
              "aes256-ctr",
              "aes128-gcm@openssh.com",
              "aes256-gcm@openssh.com",
          },
      },
  }
  

• 网络层保活配置缺失
  当前代码仅配置了15秒的握手超时，没有设置TCP层保活机制。如果网络路径中存在NAT网关、企业防火墙等设备，会静默丢弃无流量的空闲连接，导致握手阶段的读请求被中间设备拦截触发超时。可替换原生ssh.Dial逻辑，自定义带保活配置的TCP拨号器：

  dialer := &net.Dialer{
      Timeout:   15 * time.Second,
      KeepAlive: 30 * time.Second,
  }
  tcpConn, err := dialer.Dial("tcp", "remote-server:22")
  if err != nil {
      panic(err)
  }
  sshConn, chans, reqs, err := ssh.NewClientConn(tcpConn, "remote-server:22", config)
  if err != nil {
      panic(err)
  }
  client := ssh.NewClient(sshConn, chans, reqs)
  

  注意：使用该段代码需额外导入标准库的net包，无需修改原有业务逻辑。

• 基础配置校验点
  • 确认代码中填写的目标服务器地址、端口，和命令行ssh连接时使用的地址完全一致，避免把VPC内网IP填到公网连接的场景中，导致路由到错误的目标地址被丢包
  • 确认本地系统防火墙没有单独拦截Go程序的出站22端口流量：系统防火墙通常不会拦截自带的ssh命令，但可能会对未知第三方程序的出站流量做静默拦截
  • 该报错和HostKeyCallback配置无关：如果是主机密钥校验失败，会直接返回明确的校验错误，不会触发读超时

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