GitHub推送代码报Permission to ORG/REPO denied to USER排查

该陌生账号的认证信息没有出现在你排查的明文配置文件中，核心原因是你遗漏了非明文存储、优先级高于全局Git配置的认证来源，常见来源按出现概率排序：

1. 系统级凭据管理器缓存
   绝大多数桌面系统的Git默认不会把认证信息存在明文的~/.git-credentials文件中，而是存在系统加密凭据库：
   • macOS下存在「钥匙串访问」的互联网密码分类中
   • Windows下存在「凭据管理器」的Windows凭据分类中
   • Linux桌面环境下存在libsecret Secret Service中
     如果你之前在这台设备上登录过该陌生用户的GitHub账号、帮他提交过代码、处理过他参与的仓库的PR时选择了记住凭据，对应认证信息就会存在加密凭据库中，Git推送时会优先读取这里的内容，全局grep明文文件自然搜不到匹配结果。
2. 仓库本地Git配置覆盖
   你排查的是全局Git配置，没有检查目标仓库本地的.git/config文件：
   • 可能该仓库单独配置了credential.username为陌生用户
   • 可能仓库的remote地址被写成了夹带用户名的格式：https://陌生用户名@github.com/ORG/REPO.git
     很多用户全局grep时会默认跳过.git这类隐藏目录，自然搜不到对应配置。
3. SSH代理缓存的异常密钥
   你只排查了~/.ssh目录下的静态密钥文件，没有检查ssh-agent当前加载的运行时密钥：如果之前临时加载过该陌生用户的SSH私钥（比如帮他调试仓库权限时操作过），SSH连接GitHub时会优先使用agent中缓存的密钥，GitHub会直接将请求识别为对应密钥绑定的陌生用户，不需要在配置文件中写任何用户信息。
4. 网络代理的认证缓存
   如果你使用公司网络、本地代理工具访问GitHub，部分代理会缓存之前请求带过的GitHub认证头，自动注入到后续的Git推送请求中，导致身份被识别为之前登录过的陌生用户。

你提到该陌生用户是你参与过的其他仓库的贡献者，刚好对应第一种场景：你在处理那个共同参与的仓库时，某次操作输入过该用户的认证信息并选择了记住，被系统凭据库缓存了下来。而该用户对你当前推送的目标仓库没有访问权限，GitHub校验请求携带的身份时就会抛出权限拒绝错误。

• 清理系统凭据库中所有GitHub相关的缓存凭据：
  • macOS：打开钥匙串访问，搜索github.com，删除所有匹配的互联网密码条目
  • Windows：打开凭据管理器，找到所有前缀为git:https://github.com的凭据条目全部删除
  • Linux：执行对应secret-tool命令清理libsecret中存储的GitHub相关凭据
• 进入目标仓库根目录，执行git remote -v检查远程地址，如果地址中夹带了陌生用户名，重新设置为不带用户名的官方地址：git remote set-url origin https://github.com/ORG/REPO.git（或你自己的SSH地址）
• 执行ssh-add -l查看SSH代理当前加载的所有密钥，把不属于你本人的密钥通过ssh-add -d 私钥路径命令移除，同时检查~/.ssh/config中是否存在针对github.com的异常主机规则
• 重新执行推送操作，按提示输入你本人的GitHub认证信息即可，后续凭据会被正确缓存为你自己的账号。

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