Git SSH连通测试正常但仓库操作报publickey权限拒绝

ssh -T git@gitlab.server.com 返回欢迎信息仅能证明你当前默认SSH会话提交的密钥可被GitLab服务端识别为合法用户身份，不代表Git操作发起的SSH连接一定会使用这把有效密钥，这类故障90%以上为客户端配置问题，无需优先调整服务端，按以下顺序排查即可：

• 第一步：校验远程仓库地址
  进入本地仓库目录执行git remote -v，确认fetch/push对应的远程地址格式为git@gitlab.server.com:<namespace>/<repo>.git，确认域名、仓库路径无拼写错误，不存在自定义端口、错误SSH别名等配置偏差。
• 第二步：定位Git操作实际使用的密钥
  执行带SSH调试日志的仓库操作，查看完整握手过程：

  GIT_SSH_COMMAND="ssh -v" git pull
  

  在输出日志中找到Offering public key:字段，核对后面列出的所有密钥路径，确认其中包含你上传到GitLab的对应私钥。
  高频触发场景：
  • 本地ssh-agent缓存了过期/无效的旧密钥，SSH连接优先发送了无效密钥，被服务端拒绝
  • ~/.ssh/config中为gitlab.server.com配置了独立的IdentityFile路径，指向了非你当前上传的密钥
  • 你使用的Git客户端（如IDE内置Git、第三方GUI客户端）自带独立SSH运行环境，未读取系统用户目录下的.ssh配置和密钥
• 第三步：快速排除配置干扰验证
  执行命令强制指定有效私钥发起Git操作，跳过所有默认配置加载逻辑：

  GIT_SSH_COMMAND="ssh -i /path/to/your/valid/private_key -o IdentitiesOnly=yes" git pull
  

  如果该命令执行成功，可100%确认故障来自本地SSH配置加载逻辑，和服务端无关，只要修正对应配置、清理ssh-agent内无效密钥即可。
• 第四步：服务端侧排查（仅当前面步骤全部无效时检查）
  确认客户端配置无问题后，再联系GitLab管理员检查以下配置：
  • 你的账号是否被移出对应仓库/群组的访问列表，或权限被调整为无访问权限
  • 服务端是否配置了IP白名单、访问时段限制，你当前出口IP不在允许范围内
  • 服务端GitLab实例的仓库目录权限、gitlab-shell运行状态是否异常，可通过服务端/var/log/gitlab下的对应日志定位具体拒绝原因
  • 你的账号是否被触发了安全策略限制，如强制2FA校验、临时推送封禁等

内容的提问来源于stack exchange，提问作者Stephan Häberle