GitLab流水线通过SSH连接EC2实例超时问题排查求助

问题描述 #

尝试通过.pem密钥文件，借助GitLab流水线建立与EC2实例的SSH连接，gitlab-ci.yml的Deploy阶段配置如下：

"Deploy":
  stage: deploy
  before_script:
    - apk update && apk add openssh
    - echo "$AWS_EC2_KEY" > Main.pem
    - chmod 0400 Main.pem

  script:
    - cat Main.pem
    - echo $AWS_EC2_HOST
    - echo "docker info" | ssh -o StrictHostKeyChecking=no -i Main.pem ec2-user@$AWS_EC2_HOST

执行时出现Operation timed out（连接超时）错误，已验证环境变量和.pem文件内容正确，本地机器执行相同操作可成功连接，需排查流水线中SSH连接异常的原因。

可能的原因及排查方向 #

• EC2安全组未开放GitLab Runner的IP访问
  本地能连接是因为你的公网IP在安全组允许列表内，但GitLab Runner（共享或自托管）的IP不在EC2实例安全组的入站规则里，导致请求被拦截。
  排查：查看EC2安全组入站规则，确认是否允许GitLab Runner的公网IP访问22端口；若使用共享Runner，临时测试可开放0.0.0.0/0（生产环境不推荐），长期方案建议改用自托管Runner并将其IP加入安全组。

• GitLab Runner所在网络限制出站访问
  若为自托管Runner，其所在网络可能有防火墙或NAT规则，禁止出站访问EC2的22端口。
  排查：在Runner所在机器手动执行相同SSH命令，验证是否能连接；若失败，检查Runner网络的出站防火墙规则。

• EC2实例使用私有IP且Runner无法访问VPC内网
  如果AWS_EC2_HOST填写的是EC2私有IP，而GitLab Runner不在同一VPC、也无VPN/专线连接到VPC，自然无法访问。
  排查：确认AWS_EC2_HOST为EC2公网IP；若需使用私有IP，需将Runner部署到VPC内，或通过VPC对等连接打通网络。

• SSH命令的用户或端口不匹配
  不同EC2 AMI的默认SSH用户名不同（比如Ubuntu是ubuntu，Amazon Linux是ec2-user），若流水线中用户名错误，或EC2修改了SSH端口但命令未指定，也会引发超时。
  排查：核对EC2实例的SSH用户名和端口，若端口非默认22，在SSH命令中添加-p 自定义端口参数。

• 密钥文件写入格式异常
  若AWS_EC2_KEY环境变量存储时将换行符转义为\n，执行echo "$AWS_EC2_KEY" > Main.pem会导致密钥文件格式错误，进而引发连接问题（虽大概率是权限/密钥错误，但也需排查）。
  排查：在流水线script中保留cat Main.pem步骤，对比输出的密钥格式与本地文件是否一致，检查是否存在换行丢失或转义错误。

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