GitLab Runner出现ssh: Operation timeout错误的原因排查

先指出你CI配置里的明显错误：

• 路径拼写错误：before_script里的chmod 700 ~/.shh是笔误，正确路径应为~/.ssh，这个错误会导致.ssh目录权限配置失效，虽不一定直接引发超时，但会影响SSH的正常配置加载。

针对ssh: Operation timeout错误，从以下方向逐一排查：

1. 私钥处理环节验证 #

先确认私钥是否正确加载，排除密钥层面的问题：

• 在before_script中添加ssh-add -l命令，查看私钥是否成功加入ssh-agent。若输出为空，说明私钥加载失败。
• 检查GitLab CI变量$KEY：确保变量包含完整的SSH私钥内容（包含-----BEGIN RSA PRIVATE KEY-----和-----END RSA PRIVATE KEY-----首尾行），且变量类型设为「Protected」或「Masked」，避免格式被转义。
• 确认目标服务器的~/.ssh/authorized_keys文件已添加该私钥对应的公钥，同时保证authorized_keys权限为600、.ssh目录权限为700。

2. 网络与防火墙排查 #

超时最常见的原因是网络连通性问题：

• 测试GitLab Runner所在机器到目标服务器的22端口连通性：在Runner机器上执行telnet $SSH_HOST 22或nc -zv $SSH_HOST 22，确认端口是否可访问。
• 检查目标服务器的防火墙/安全组：是否放行Runner出口IP的22端口入站请求。
• 核对$SSH_HOST变量值：确保是正确的IP地址或域名，无拼写错误。

3. SSH命令调试 #

添加 verbose 参数获取详细连接日志：
将script中的SSH命令修改为：

ssh -v -o StrictHostKeyChecking=no $SSH_USER@$SSH_HOST "echo Hello"

-v参数会输出完整的连接过程日志，可定位是DNS解析失败、密钥验证环节出错还是连接被拦截。

4. 变量配置检查 #

确认$SSH_USER和$SSH_HOST已在GitLab项目的「Settings > CI/CD > Variables」中正确配置，无空值或拼写错误。

修正后的CI配置示例 #

stages:
  - deploy
deploy:
  stage: deploy
  before_script:
    - eval $(ssh-agent -s)
    - echo "$KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh  # 修正路径拼写错误
    - ssh-add -l  # 新增：验证私钥加载状态
  script:
    - ssh -v -o StrictHostKeyChecking=no $SSH_USER@$SSH_HOST "echo Hello"

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