GitLab CI/CD拉取SSH子模块报Host key verification failed解决求助

首先明确报错本质：Host key verification failed 发生在SSH连接建立的主机信任校验阶段，远早于SSH身份鉴权环节，你之前猜测的“公钥未注册到GitLab账号”根本不是当前报错的根因。
你当前的基础配置已经正确开启了递归子模块拉取，只需要补充对应配置就能解决问题，以下是两种经过验证的标准实现：

方案1：依赖GitLab内置CI能力（零手动密钥配置，最推荐） #

GitLab CI 内置了完整的子模块拉取逻辑，只要在现有.gitlab-ci.yml中补充基础变量，即可自动处理子模块的鉴权与连接问题，无需手动配置任何SSH公钥、主机信任规则：

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  # 显式声明拉取策略，确保子模块URL的自动重写逻辑生效
  GIT_STRATEGY: fetch

test:
  script:
    - bash ./foo.sh

cpplint:
  script:
    - bash ./bar.sh

注意：这个方案生效的前提是，触发CI流程的用户/账号，对两个子模块仓库a/xfoo、a/xbar至少拥有只读权限——GitLab会自动使用内置的临时CI_JOB_TOKEN，把.gitmodules中的SSH格式URL重写为可鉴权的临时拉取地址，全程不会走交互式SSH校验流程。

方案2：自定义Runner环境的手动配置（适配自建非托管Runner） #

如果你的Runner是自行搭建的离线/定制化环境，无法依赖GitLab内置的自动重写逻辑，可以直接把主机信任配置提为全局CI流程，直接消除Host key校验报错：

# 全局前置脚本，所有作业自动继承，无需重复编写相同逻辑
before_script:
  - mkdir -p ~/.ssh
  - chmod 700 ~/.ssh
  # 自动扫描拉取gitlab.com的合法主机公钥，写入运行环境的信任列表
  - ssh-keyscan gitlab.com >> ~/.ssh/known_hosts

test:
  script:
    - bash ./foo.sh

cpplint:
  script:
    - bash ./bar.sh

关于SSH公钥配置的常见误区 #

你之前考虑的“把公钥加到对应GitLab账号”的操作，仅在解决完主机信任问题后、遇到Permission denied (publickey)类鉴权报错时才需要配置，操作规则：

• 不要把个人账号的SSH公钥/私钥直接写入CI配置，避免个人全仓库权限泄露
• 如果必须走纯SSH协议拉取子模块，给每个子模块仓库配置只读Deploy Key，将Deploy Key对应的私钥存在主项目的CI/CD加密变量中，在CI作业中加载使用即可，权限范围最小更安全

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