GitLab CI/CD通过SSH部署报knownhosts: key is unknown错误

报错根因 #

该报错和之前配置的SSH登录密钥无关，核心原因是gitlab-runner运行身份对应的SSH配置中，没有存储目标部署机器的主机公钥指纹，SSH严格主机校验机制直接拦截了未授信的连接。

排查解决步骤 #

• 第一步：确认gitlab-runner的实际运行用户
  多数人配置SSH时会误把密钥、指纹存在当前登录用户/root用户目录下，和runner实际运行用户不匹配。先执行命令确认运行用户：

  ps aux | grep gitlab-runner
  

  默认情况下gitlab-runner服务会以同名gitlab-runner用户运行，确认后切换到该用户操作：

  su - gitlab-runner
  

• 第二步：添加目标服务器的主机指纹到known_hosts
  执行以下命令拉取目标部署机的SSH主机公钥，写入当前用户的known_hosts文件，替换命令里的端口、服务器地址为你实际的部署机参数：

  # SSH端口默认是22，如果你改了端口就替换-p后面的值
  ssh-keyscan -p 22 你的部署机IP/域名 >> ~/.ssh/known_hosts
  

  验证配置是否生效：手动执行SSH连接部署机命令，如果不需要手动输入yes确认主机指纹就能进入下一步认证，说明指纹添加成功：

  ssh 部署机登录用户名@部署机IP/域名
  

  测试环境临时快速修复方案（生产环境不推荐）：如果不想做主机校验，可以编辑~/.ssh/config文件添加以下配置跳过校验：

  Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
  

• 第三步：修正SSH目录权限
  SSH对配置文件权限有强制要求，权限不符合规则时会直接读取配置失败：

  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/known_hosts
  chown -R gitlab-runner:gitlab-runner ~/.ssh
  

• 第四步：重启gitlab-runner服务生效
  以systemd管理的服务为例，执行重启命令：

  systemctl restart gitlab-runner
  

  重启后重新触发staging分支的CI流水线即可正常运行。

常见踩坑点 #

如果你注册SSH类型runner时填写的目标地址是域名，ssh-keyscan的时候就不要用IP拉取指纹，主机名不匹配会触发同样的报错，保证两个环节的地址完全一致即可。

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