GitLab SSH 连接故障排查复盘

本次 GitLab SSH 连接故障表现为：ssh -T git@<server> 返回 Permission denied (publickey)。我们对整个 SSH 认证链条进行了全方位排查，最终在操作系统底层锁定了问题。以下是排查链路。

第一步：确认客户端和密钥同步（排除应用层问题）

首先，我们排除了最常见的密钥不匹配和配置未生效的问题。

  1. 对比密钥指纹

我们需要确认本地私钥与 GitLab 界面上记录的公钥是否一致。

  • 执行命令（本地）：
    ssh-keygen -l -f ~/.ssh/id_ed25519_github_work.pub
  • 结果确认：
    输出的 SHA256 指纹与 GitLab 网页界面上显示的内容完全一致。
  1. 检查服务器端密钥同步

确认 GitLab 是否已将公钥写入服务器的 SSH 授权文件。

  • 执行命令（服务器）：
    sudo cat /var/opt/gitlab/.ssh/authorized_keys | grep "您的密钥特征码"
  • 结果确认：
    文件中存在对应的公钥记录（例如 key-23），说明 GitLab 的同步机制正常。
  1. 检查 GitLab 服务状态

排除服务宕机导致连接被拒的可能性。

  • 执行命令（服务器）：
    sudo gitlab-ctl status
  • 结果确认：
    核心服务如 gitlab-workhorse 和 puma 均显示状态为 run，服务运行正常。

第二步：追踪 GitLab Shell 启动失败（定位执行环境问题）

既然密钥已同步且服务正常，但连接仍被拒绝，问题必然发生在 OpenSSH 服务器尝试启动 GitLab Shell 程序的瞬间。

检查 GitLab Shell 日志

  • 执行命令（服务器）：
    sudo tail -n 50 /var/log/gitlab/gitlab-shell/gitlab-shell.log
  • 结果确认：
    无任何输出。这说明 GitLab Shell 程序根本没有机会启动，或者在写入日志前就被系统终止了。故障点位于比 GitLab 应用更底层的环境。

第三步：深入 SSHD 日志（锁定操作系统底层故障）

当应用层日志无效时，必须查看 OpenSSH 服务器自身的系统日志，寻找拒绝会话的真实原因。

检查系统认证日志

  • 执行命令（服务器）：
    sudo tail -n 50 /var/log/auth.log
  • 发现致命日志：
    Dec 2 16:36:06 ... sshd[3305327]: User git not allowed because account is locked

最终确诊：
权限被拒与 GitLab 密钥毫无关系，而是因为 OpenSSH 服务器发现操作系统的 git 专用账户处于锁定状态。sshd 在进行公钥认证流程之前，就直接根据操作系统账户状态拒绝了连接。

解决方案

故障原因：
操作系统 git 账户被锁定 (account is locked)。

修复步骤：
使用 usermod 命令解锁 git 账户。为了安全起见（防止无密码账户被系统拦截），我们设置一个无法用于登录的锁定哈希。

  • 执行命令（服务器）：
    sudo usermod -p '*LOCKED*' git

验证：
再次执行 ssh -T git@<server>，成功看到 Welcome to GitLab 提示。

标签: none

评论已关闭