先把话放在前面HTTP Basic: Access denied这个报错跟你的网络通不通没什么关系。它出现的时候你的电脑和代码托管平台之间其实已经建立连接了只不过在验明正身这一关服务端干脆利落地按下了拒绝键。很多第一次遇到的人会在这条提示面前懵掉以为代码仓库被锁、账号被封、甚至以为是公司网络把 Git 给墙了。实际上问题基本都出在认证本身——要么是凭据不对要么是凭据对但你没资格进门。这类问题最磨人的地方在于它出现得毫无预兆今天还能正常git pull明天早上git push就突然报错。而且同一个报错在不同场景下的触发原因完全不一样有可能是密码过期有可能是缓存了旧密码也有可能是 token 权限被收窄。这篇文章会用最直白的语言把这条报错背后的认证机制、常见触发场景、完整的排查流程以及多平台下容易踩的坑全部梳理一遍。不管你是刚入行的前端实习生还是负责公司 GitLab 维护的运维老手这套思路都能直接用上。1. 先搞清楚这个报错到底是谁在拒绝你1.1 一个传话筒式的报错HTTP 认证链路是怎么走的先解释一下这条报错为什么会存在。Git 在使用 HTTP/HTTPS 协议访问远程仓库时调用的是 HTTP 标准里的 Basic Authentication基本认证机制。每次请求时客户端会在请求头里带上一段Authorization: Basic xxx其中 xxx 是用户名:密码组合经过 Base64 编码后的字符串。服务端收到后解码、查库、比对通过就放行不通过就返回 401 状态码响应体里附带一句类似HTTP Basic: Access denied的描述。关键在于这句报错的作者并不是 Git 本身。Git 客户端只是把服务端返回的 401 响应翻译成人类能看懂的提示然后展示在终端里。所以你看到的HTTP Basic: Access denied本质上是服务端明确表示凭据验证失败或没有权限。这个机制可以类比成小区门禁访问者报了门牌号保安查了业主名单觉得查无此人或权限不足于是直接拒绝进入。此时问题不在小区门口的马路有多堵也不在门禁设备坏没坏而在你报的信息能不能在登记表里对上号。所以排查时永远不要先怀疑网络先检查凭据。1.2 服务端为什么会拒绝你的密码核心原因清单按照我的实战经验这个报错的触发原因可以收敛成以下几类基本覆盖九成以上场景密码或用户名本身错误、被重置、过期未更新操作系统层面的凭据缓存里存了一份旧密码Git 每次都拿旧密码去认证账号存在但仓库权限被收回比如被移出项目组、仓库改成私有平台开启了二次验证2FA导致单纯用密码无法通过认证必须用个人访问令牌TokenToken 过期、被吊销或者 Token 本身没有分配对应仓库的读写权限代理服务器或安全网关在中间拦截并篡改了认证请求头导致服务端收到了一组无法解析的凭据。很多人在排查时习惯先去改git config里的用户名、邮箱或者反复重新 clone这些动作其实都没打到点子上。因为user.name和user.email只影响提交记录里的作者信息跟远程仓库的 HTTP 认证完全是两套体系改它们对该报错毫无作用。认清这一点就能少折腾很多无用功。2. 最常见的三大类触发场景逐一对号入座2.1 场景一密码本身不对或者已经被改过这个场景看着最简单却最容易让人陷入死循环。尤其在公司环境里很多代码托管平台会强制要求 90 天或 180 天改一次密码或者统一接入公司账号系统。某个周一早上你收到密码即将过期的邮件改完密码VS Code 里的 Git 插件还老老实实存着旧密码于是一整天所有拉取推送操作都在报HTTP Basic: Access denied。另一个高频踩坑点是用户名填错。很多平台支持用注册邮箱登录网页端但 Git 命令行认证时要求的却是你的用户名Username而不是邮箱。有些平台允许两者都行有些平台严格区分。比如同一个账号网页登录填邮箱没问题但 Git 操作时填邮箱就会报 Access denied。所以遇到这个报错第一件事应该是去浏览器打开代码托管平台的网页版用你准备用在那台电脑上的账号密码登录一次看能不能正常登录。能登录说明凭据本身没问题往缓存方向排查不能登录说明凭据已经失效先去重置密码再说。2.2 场景二操作系统的记性太好缓存了旧凭据这个场景是很多人排查时最想不到的。Git 在第一次通过 HTTPS 认证时通常会调用系统的凭据助手credential helper把凭据保存下来。Windows 上存进凭据管理器macOS 上存进钥匙串Linux 上则取决于配置可能存成明文文件也可能存入系统密钥环。问题就出在这当你改了密码或者换了 TokenGit 下次请求时还是会先读取缓存里的旧凭据发过去于是服务端返回 Access denied。你明明在终端里输入了新密码甚至连续输了三遍但 Git 可能压根没让你输它直接把缓存里的旧值当作答案交上去了。这时候你再怎么输入正确的密码都没用必须先把缓存杀掉。Windows 上清除缓存的具体命令是cmdkey /list cmdkey /delete:git:https://git.example.com也可以打开控制面板 → 用户账户 → 凭据管理器 → Windows 凭据找到git:https://git.example.com或类似条目手动删除。macOS 上用git credential-osxkeychain erase回车后会提示输入 protocol、host 等字段按提示填写后空行结束即可。Linux 上检查一下 credentials 文件git config --global --get credential.helper rm -f ~/.git-credentials这招奏效的案例特别典型。有一次我帮同事排查他折腾了一下午改密码、删仓库、重新 clone还是报这个错最后我让他打开 Windows 凭据管理器发现里面躺着一条三年前的旧密码删掉后一次通过。说白了很多时候不是 Git 在为难你是操作系统太会记事了。2.3 场景三账号在但你没资格密码没问题、缓存也清干净了依然报 Access denied那就得往授权方向想。典型情况包括项目管理员把你移出了成员列表仓库从内部公开改成私有平台管理员调整了组的可见性。这些情况下你的账号本身有效但服务端判断你对目标仓库没有读取或写入权限返回的信息同样是 Access denied。还有一种容易被忽略的情况平台启用了单点登录SSO或组织级访问限制。即便你有平台账号如果没在这个组织后台完成授权绑定访问该组织下的私有仓库也会被拒绝。此外如果仓库 URL 是 HTTPS 开头的并且平台证书链异常比如自签名证书、内部 CA 未导入系统信任库Git 可能先报 SSL 证书错误配置了sslVerifyfalse之后又转成 Access denied。这属于证书信任和认证交织在一起的坑后面单独讲。3. 从翻车现场到成功推送的标准排查流程3.1 第一步先给凭据做个体检别急着敲命令改配置先用最原始的方式验证一下凭据本身到底能不能用。推荐用curl直接请求平台的 API 接口绕开 Git 的缓存机制看看服务端认不认这组账号密码或 Token。假设公司内网平台地址是git.example.com验证账号密码是否有效curl -u 你的用户名:你的密码 https://git.example.com/api/v3/user如果返回一段包含用户信息的 JSON说明账号密码有效问题出在 Git 缓存或权限配置上。如果返回 401 或Authentication failed说明凭据本身已经失效去重置或换 Token。用 curl 验证的好处是它每次请求都是实时构造认证头不经过 Git 的凭据助手能真实反映服务端的态度。如果是验证 Token格式通常是curl -H Authorization: Bearer 你的Token https://git.example.com/api/v3/user这一步做完整个排查方向就清晰了是凭据问题还是权限问题一眼便知。3.2 第二步清空一切可能的缓存层确认凭据有效后接下来的目标就是清理所有可能残留旧凭据的地方。注意这里说的是一切因为有些环境存在多层缓存叠加的情况。比如 Windows 上既用了系统凭据管理器又无意中在~/.git-credentials里存了一份或者 IDE 内置的 Git 插件自己维护了一套账号信息。完整的清理动作如下检查并删除系统凭据管理器里的条目Windows 的 cmdkey、macOS 的钥匙串删除~/.git-credentials明文文件执行git config --global --unset credential.helper取消自动保存查看项目目录下的.git/config以及全局~/.gitconfig看有没有多余的 URL 重写规则。清完缓存的本质是让 Git 回到每次认证都老老实实询问你的原始状态。此时重新执行git pushGit 会提示输入用户名和密码输入新密码或 Token 后正常推送。如果还不行进入第三步。3.3 第三步换一种认证方式重建信任到了这一步最省时间的方式就是放弃密码认证改用平台推荐的长效凭据方案——个人访问令牌Personal Access Token。很多平台出于安全考虑已经不允许直接用账号密码走 Git 操作或者对密码认证做了额外限制。Token 的好处是作用域可以精细控制、可单独吊销、可设过期时间不用把账号密码暴露在终端历史里。生成 Token 的位置通常在代码托管平台的个人设置 → 访问令牌或Access Tokens页面。创建时务必勾选需要的权限范围比如读取仓库、推送代码、读取用户信息等然后设置一个合理的过期时间。生成后只会显示一次记得立刻复制保存。拿到 Token 之后可以用它替代密码git push Username: 你的用户名 Password: 你的Token粘贴进去即可不回显嫌每次输入太麻烦可以在 URL 里带 Token 前置但注意不要把包含 Token 的 URL 写进任何会被他人看到的文件或提交记录里git remote set-url origin https://你的用户名:你的Tokengit.example.com/组名/仓库.git如果网络环境允许另一个一劳永逸的办法是切换到 SSH 协议。SSH 基于密钥对认证没有密码过期问题也不受 HTTP Basic 的约束。操作流程是本地生成密钥对公钥添加到平台账户的 SSH Keys 列表远程地址从https://git.example.com/...换成gitgit.example.com:组名/仓库.git格式。三种认证方式的对比很直观对比维度账号密码个人访问令牌 TokenSSH 密钥有效期随密码重置/过期而失效可设置过期时间长期有效权限控制继承账号全部权限细粒度勾选作用域按密钥绑定角色使用便捷性需要反复输入配置后免输入配置后免输入安全风险明文传输风险高日志容易泄露可单独撤销风险可控私钥泄露风险大适合场景临时验证日常开发、CI/CD长期稳定使用我的建议是个人电脑日常开发用 SSH 最省心公司电脑或临时环境用 Token 结合凭据管理器最平衡。4. 多平台与多场景下的差异别拿一个地方的方案生搬硬套4.1 Windows / macOS / Linux 三种环境下的处理差异同一个 Git 报错在不同操作系统上排查路径差别挺大的。Windows 上凭据默认由 Git Credential Manager 管理它背后可能是 Windows 凭据管理器也可能是 Git 安装目录下自带的凭据组件。清缓存时用控制面板里的凭据管理器最直观也可以在命令行使用cmdkey /list看到完整条目。macOS 的钥匙串有时会同时存在多条同名条目删除时最好把github.com相关的全部列出来看清楚再删。命令行方式git credential-osxkeychain erase hostgit.example.com protocolhttps注意末尾的空行不能省略这表示输入结束。如果嫌麻烦也可以用钥匙串访问App 直接搜索git.example.com删除。Linux 上最常见的是credential.helperstore它会生成一个明文文件存放密码。这个文件在~/.git-credentials里一删了之。但如果配置的是libsecret或gnome-keyring就需要用系统密钥管理工具清理或者执行printf protocolhttps\nhostgit.example.com\n\n | git credential reject另外提醒一句很多 Windows 用户在公司域环境里账号格式是域\用户名在 Git 里输入认证信息时经常因为反斜杠转义问题导致认证失败。这时候在 curl 里可以用域\\用户名双反斜杠转义但在 Git 命令行里通常更适合直接输入用户名域名或先切换成 Token 认证绕开这个坑。4.2 CI/CD 与服务器场景里的 Access denied这个问题在 CI/CD 流水线里出现得更隐蔽。本地明明一切正常一到构建服务器就报HTTP Basic: Access denied。核心原因通常是流水线里使用的 Token 过期了、权限被删了或者环境变量没有正确注入。在 CI 配置中一般建议通过项目变量/环境变量传入 Token然后在构建脚本里动态拼接认证信息。一个比较通用的做法是使用.netrc文件。在构建机上创建~/.netrc内容如下machine git.example.com login 你的用户名 password 你的Token然后确保文件权限为 600chmod 600 ~/.netrcGit 在读取远程仓库时如果发现没有其他凭据源就会尝试读取~/.netrc里的登录信息。这个方法在 Linux 服务器、Docker 容器、Jenkins 执行机上都通用。但千万注意.netrc是明文文件如果构建机是共享的或镜像会被分发就要改用环境变量注入的方式避免 Token 泄漏。还有一个实战小技巧在 CI 脚本的最前面加上export GIT_TERMINAL_PROMPT0。这个环境变量可以让 Git 在需要交互式输入密码时直接失败退出而不是卡死在等待输入的状态。CI 环境里卡死比报错更让人头疼因为它会导致任务超时却不告诉你原因。加上这一行Git 会立刻报错提示缺少凭据方便快速定位。4.3 代理与安全网关也可能背锅最后必须提一类最容易被忽略的情况代理干扰。公司内网经常有统一出口代理或安全扫描网关它们会拦截 HTTP 流量做审计有时会改动 Authorization 请求头。于是客户端明明发送了正确的凭据经过中间层后服务端收到的是残缺或编码错乱的信息返回 Access denied。这种问题的特征是同一套凭据在家里网络能正常使用在公司网络就报错。遇到这种情况先做个交叉验证git config --global --unset http.proxy git config --global --unset https.proxy然后重新试一次git ls-remote https://git.example.com/组名/仓库.git。如果不再报 Access denied说明就是代理的问题。解决方式要么在 Git 配置里正确设置代理地址和认证要么在环境变量里配置NO_PROXY把内网平台地址排除在代理之外。与之相似的还有平台使用自签名证书或内部 CA 证书的情况。Git 默认会校验证书链对不受信任的证书直接报 SSL 错误被设置成忽略证书校验后又可能在认证阶段出现各种奇奇怪怪的问题包括 Access denied。严谨的解决方案是把内部 CA 证书导入系统的信任链然后在 Git 里显式指定git config --global http.sslCAInfo /路径/你的CA证书.crt这一通操作下来基本能把环境因素排干净。5. 一次搞定面向未来的认证配置与团队协作规范5.1 从源头减少 Access denied 的团队约定个人踩坑能解决一时问题但一个团队里如果人人都在自己的电脑上反复折腾认证效率损失相当可观。我在团队里推行过几条简单的约定效果显著所有项目统一使用 SSH 密钥认证不用 HTTPS 推代码新成员入职时第一件事就是生成密钥、添加公钥、clone 仓库验证连通性如果必须用 HTTPS统一使用个人访问令牌并设置一年或半年的过期提醒技术文档和 README 里严禁出现包含账号密码或 Token 的远程地址一旦发现立即撤销 Token密码或 Token 变更后同步检查自己的电脑凭据缓存特别是 Windows 用户建立一份认证问题排查小抄放在团队 Wiki 里内容就是这篇文章的浓缩版。这些约定不一定能消灭所有认证问题但可以把报错频率降到很低。新同事不会再对着 Access denied 干瞪眼运维同事也不用反复远程帮人删缓存。5.2 我建议的日常命令与逃生工具清单最后分享一份我常年驻留在终端笔记里的命令清单。当 Access denied 再次出现时按顺序执行基本不慌# 1. 查看当前远程地址 git remote -v # 2. 直接验证凭据是否有用换成你自己的 URL curl -u 用户名:密码 https://git.example.com/api/v3/user # 3. 查看 Git 会使用哪个凭据助手 git config --global --get credential.helper # 4. 清空缓存文件 / 删除凭据条目 rm -f ~/.git-credentials cmdkey /delete:git:https://git.example.com # Windows # 5. 换一种认证方式测试远端可达性 git ls-remote https://git.example.com/组名/仓库.git # 6. CI 环境快速失败 export GIT_TERMINAL_PROMPT0这套清单覆盖了凭据有效性和缓存清理两个核心环节剩下的就是去平台页面检查权限与 Token 作用域。如果这些都做完了仍然报错再考虑代理、证书、防火墙等环境因素。就我个人经验而言Access denied 这个报错最大的特点不是难而是乱。它把密码错误、token 权限不足、凭据缓存、权限变更、中间层干扰全都装进了同一个报错文案里导致很多人被迫在多个方向上同时碰运气。但只要理解了 HTTP Basic 认证的转发链路再按先验凭据、再清缓存、后查权限、最后查环境的顺序操作绝大多数情况都能在十分钟内解决。我自己踩过最惨的一次是被平台强制改密后Windows 凭据管理器里还躺着旧密码连续两个小时以为是账号被封最后发现只是 CtrlS 前忘了下一步。从那以后我养成了一个习惯任何密码类变更后第一件事先清 Git 凭据缓存再执行第一次拉取。这个习惯保住了我后面很多个下午的平静心情。 
长河君 · 2026/10/17 9:34:13 · 阅读 1.2k Git HTTP Basic: Access denied 报错原因与解决全攻略
先把话放在前面HTTP Basic: Access denied这个报错跟你的网络通不通没什么关系。它出现的时候你的电脑和代码托管平台之间其实已经建立连接了只不过在验明正身这一关服务端干脆利落地按下了拒绝键。很多第一次遇到的人会在这条提示面前懵掉以为代码仓库被锁、账号被封、甚至以为是公司网络把 Git 给墙了。实际上问题基本都出在认证本身——要么是凭据不对要么是凭据对但你没资格进门。这类问题最磨人的地方在于它出现得毫无预兆今天还能正常git pull明天早上git push就突然报错。而且同一个报错在不同场景下的触发原因完全不一样有可能是密码过期有可能是缓存了旧密码也有可能是 token 权限被收窄。这篇文章会用最直白的语言把这条报错背后的认证机制、常见触发场景、完整的排查流程以及多平台下容易踩的坑全部梳理一遍。不管你是刚入行的前端实习生还是负责公司 GitLab 维护的运维老手这套思路都能直接用上。1. 先搞清楚这个报错到底是谁在拒绝你1.1 一个传话筒式的报错HTTP 认证链路是怎么走的先解释一下这条报错为什么会存在。Git 在使用 HTTP/HTTPS 协议访问远程仓库时调用的是 HTTP 标准里的 Basic Authentication基本认证机制。每次请求时客户端会在请求头里带上一段Authorization: Basic xxx其中 xxx 是用户名:密码组合经过 Base64 编码后的字符串。服务端收到后解码、查库、比对通过就放行不通过就返回 401 状态码响应体里附带一句类似HTTP Basic: Access denied的描述。关键在于这句报错的作者并不是 Git 本身。Git 客户端只是把服务端返回的 401 响应翻译成人类能看懂的提示然后展示在终端里。所以你看到的HTTP Basic: Access denied本质上是服务端明确表示凭据验证失败或没有权限。这个机制可以类比成小区门禁访问者报了门牌号保安查了业主名单觉得查无此人或权限不足于是直接拒绝进入。此时问题不在小区门口的马路有多堵也不在门禁设备坏没坏而在你报的信息能不能在登记表里对上号。所以排查时永远不要先怀疑网络先检查凭据。1.2 服务端为什么会拒绝你的密码核心原因清单按照我的实战经验这个报错的触发原因可以收敛成以下几类基本覆盖九成以上场景密码或用户名本身错误、被重置、过期未更新操作系统层面的凭据缓存里存了一份旧密码Git 每次都拿旧密码去认证账号存在但仓库权限被收回比如被移出项目组、仓库改成私有平台开启了二次验证2FA导致单纯用密码无法通过认证必须用个人访问令牌TokenToken 过期、被吊销或者 Token 本身没有分配对应仓库的读写权限代理服务器或安全网关在中间拦截并篡改了认证请求头导致服务端收到了一组无法解析的凭据。很多人在排查时习惯先去改git config里的用户名、邮箱或者反复重新 clone这些动作其实都没打到点子上。因为user.name和user.email只影响提交记录里的作者信息跟远程仓库的 HTTP 认证完全是两套体系改它们对该报错毫无作用。认清这一点就能少折腾很多无用功。2. 最常见的三大类触发场景逐一对号入座2.1 场景一密码本身不对或者已经被改过这个场景看着最简单却最容易让人陷入死循环。尤其在公司环境里很多代码托管平台会强制要求 90 天或 180 天改一次密码或者统一接入公司账号系统。某个周一早上你收到密码即将过期的邮件改完密码VS Code 里的 Git 插件还老老实实存着旧密码于是一整天所有拉取推送操作都在报HTTP Basic: Access denied。另一个高频踩坑点是用户名填错。很多平台支持用注册邮箱登录网页端但 Git 命令行认证时要求的却是你的用户名Username而不是邮箱。有些平台允许两者都行有些平台严格区分。比如同一个账号网页登录填邮箱没问题但 Git 操作时填邮箱就会报 Access denied。所以遇到这个报错第一件事应该是去浏览器打开代码托管平台的网页版用你准备用在那台电脑上的账号密码登录一次看能不能正常登录。能登录说明凭据本身没问题往缓存方向排查不能登录说明凭据已经失效先去重置密码再说。2.2 场景二操作系统的记性太好缓存了旧凭据这个场景是很多人排查时最想不到的。Git 在第一次通过 HTTPS 认证时通常会调用系统的凭据助手credential helper把凭据保存下来。Windows 上存进凭据管理器macOS 上存进钥匙串Linux 上则取决于配置可能存成明文文件也可能存入系统密钥环。问题就出在这当你改了密码或者换了 TokenGit 下次请求时还是会先读取缓存里的旧凭据发过去于是服务端返回 Access denied。你明明在终端里输入了新密码甚至连续输了三遍但 Git 可能压根没让你输它直接把缓存里的旧值当作答案交上去了。这时候你再怎么输入正确的密码都没用必须先把缓存杀掉。Windows 上清除缓存的具体命令是cmdkey /list cmdkey /delete:git:https://git.example.com也可以打开控制面板 → 用户账户 → 凭据管理器 → Windows 凭据找到git:https://git.example.com或类似条目手动删除。macOS 上用git credential-osxkeychain erase回车后会提示输入 protocol、host 等字段按提示填写后空行结束即可。Linux 上检查一下 credentials 文件git config --global --get credential.helper rm -f ~/.git-credentials这招奏效的案例特别典型。有一次我帮同事排查他折腾了一下午改密码、删仓库、重新 clone还是报这个错最后我让他打开 Windows 凭据管理器发现里面躺着一条三年前的旧密码删掉后一次通过。说白了很多时候不是 Git 在为难你是操作系统太会记事了。2.3 场景三账号在但你没资格密码没问题、缓存也清干净了依然报 Access denied那就得往授权方向想。典型情况包括项目管理员把你移出了成员列表仓库从内部公开改成私有平台管理员调整了组的可见性。这些情况下你的账号本身有效但服务端判断你对目标仓库没有读取或写入权限返回的信息同样是 Access denied。还有一种容易被忽略的情况平台启用了单点登录SSO或组织级访问限制。即便你有平台账号如果没在这个组织后台完成授权绑定访问该组织下的私有仓库也会被拒绝。此外如果仓库 URL 是 HTTPS 开头的并且平台证书链异常比如自签名证书、内部 CA 未导入系统信任库Git 可能先报 SSL 证书错误配置了sslVerifyfalse之后又转成 Access denied。这属于证书信任和认证交织在一起的坑后面单独讲。3. 从翻车现场到成功推送的标准排查流程3.1 第一步先给凭据做个体检别急着敲命令改配置先用最原始的方式验证一下凭据本身到底能不能用。推荐用curl直接请求平台的 API 接口绕开 Git 的缓存机制看看服务端认不认这组账号密码或 Token。假设公司内网平台地址是git.example.com验证账号密码是否有效curl -u 你的用户名:你的密码 https://git.example.com/api/v3/user如果返回一段包含用户信息的 JSON说明账号密码有效问题出在 Git 缓存或权限配置上。如果返回 401 或Authentication failed说明凭据本身已经失效去重置或换 Token。用 curl 验证的好处是它每次请求都是实时构造认证头不经过 Git 的凭据助手能真实反映服务端的态度。如果是验证 Token格式通常是curl -H Authorization: Bearer 你的Token https://git.example.com/api/v3/user这一步做完整个排查方向就清晰了是凭据问题还是权限问题一眼便知。3.2 第二步清空一切可能的缓存层确认凭据有效后接下来的目标就是清理所有可能残留旧凭据的地方。注意这里说的是一切因为有些环境存在多层缓存叠加的情况。比如 Windows 上既用了系统凭据管理器又无意中在~/.git-credentials里存了一份或者 IDE 内置的 Git 插件自己维护了一套账号信息。完整的清理动作如下检查并删除系统凭据管理器里的条目Windows 的 cmdkey、macOS 的钥匙串删除~/.git-credentials明文文件执行git config --global --unset credential.helper取消自动保存查看项目目录下的.git/config以及全局~/.gitconfig看有没有多余的 URL 重写规则。清完缓存的本质是让 Git 回到每次认证都老老实实询问你的原始状态。此时重新执行git pushGit 会提示输入用户名和密码输入新密码或 Token 后正常推送。如果还不行进入第三步。3.3 第三步换一种认证方式重建信任到了这一步最省时间的方式就是放弃密码认证改用平台推荐的长效凭据方案——个人访问令牌Personal Access Token。很多平台出于安全考虑已经不允许直接用账号密码走 Git 操作或者对密码认证做了额外限制。Token 的好处是作用域可以精细控制、可单独吊销、可设过期时间不用把账号密码暴露在终端历史里。生成 Token 的位置通常在代码托管平台的个人设置 → 访问令牌或Access Tokens页面。创建时务必勾选需要的权限范围比如读取仓库、推送代码、读取用户信息等然后设置一个合理的过期时间。生成后只会显示一次记得立刻复制保存。拿到 Token 之后可以用它替代密码git push Username: 你的用户名 Password: 你的Token粘贴进去即可不回显嫌每次输入太麻烦可以在 URL 里带 Token 前置但注意不要把包含 Token 的 URL 写进任何会被他人看到的文件或提交记录里git remote set-url origin https://你的用户名:你的Tokengit.example.com/组名/仓库.git如果网络环境允许另一个一劳永逸的办法是切换到 SSH 协议。SSH 基于密钥对认证没有密码过期问题也不受 HTTP Basic 的约束。操作流程是本地生成密钥对公钥添加到平台账户的 SSH Keys 列表远程地址从https://git.example.com/...换成gitgit.example.com:组名/仓库.git格式。三种认证方式的对比很直观对比维度账号密码个人访问令牌 TokenSSH 密钥有效期随密码重置/过期而失效可设置过期时间长期有效权限控制继承账号全部权限细粒度勾选作用域按密钥绑定角色使用便捷性需要反复输入配置后免输入配置后免输入安全风险明文传输风险高日志容易泄露可单独撤销风险可控私钥泄露风险大适合场景临时验证日常开发、CI/CD长期稳定使用我的建议是个人电脑日常开发用 SSH 最省心公司电脑或临时环境用 Token 结合凭据管理器最平衡。4. 多平台与多场景下的差异别拿一个地方的方案生搬硬套4.1 Windows / macOS / Linux 三种环境下的处理差异同一个 Git 报错在不同操作系统上排查路径差别挺大的。Windows 上凭据默认由 Git Credential Manager 管理它背后可能是 Windows 凭据管理器也可能是 Git 安装目录下自带的凭据组件。清缓存时用控制面板里的凭据管理器最直观也可以在命令行使用cmdkey /list看到完整条目。macOS 的钥匙串有时会同时存在多条同名条目删除时最好把github.com相关的全部列出来看清楚再删。命令行方式git credential-osxkeychain erase hostgit.example.com protocolhttps注意末尾的空行不能省略这表示输入结束。如果嫌麻烦也可以用钥匙串访问App 直接搜索git.example.com删除。Linux 上最常见的是credential.helperstore它会生成一个明文文件存放密码。这个文件在~/.git-credentials里一删了之。但如果配置的是libsecret或gnome-keyring就需要用系统密钥管理工具清理或者执行printf protocolhttps\nhostgit.example.com\n\n | git credential reject另外提醒一句很多 Windows 用户在公司域环境里账号格式是域\用户名在 Git 里输入认证信息时经常因为反斜杠转义问题导致认证失败。这时候在 curl 里可以用域\\用户名双反斜杠转义但在 Git 命令行里通常更适合直接输入用户名域名或先切换成 Token 认证绕开这个坑。4.2 CI/CD 与服务器场景里的 Access denied这个问题在 CI/CD 流水线里出现得更隐蔽。本地明明一切正常一到构建服务器就报HTTP Basic: Access denied。核心原因通常是流水线里使用的 Token 过期了、权限被删了或者环境变量没有正确注入。在 CI 配置中一般建议通过项目变量/环境变量传入 Token然后在构建脚本里动态拼接认证信息。一个比较通用的做法是使用.netrc文件。在构建机上创建~/.netrc内容如下machine git.example.com login 你的用户名 password 你的Token然后确保文件权限为 600chmod 600 ~/.netrcGit 在读取远程仓库时如果发现没有其他凭据源就会尝试读取~/.netrc里的登录信息。这个方法在 Linux 服务器、Docker 容器、Jenkins 执行机上都通用。但千万注意.netrc是明文文件如果构建机是共享的或镜像会被分发就要改用环境变量注入的方式避免 Token 泄漏。还有一个实战小技巧在 CI 脚本的最前面加上export GIT_TERMINAL_PROMPT0。这个环境变量可以让 Git 在需要交互式输入密码时直接失败退出而不是卡死在等待输入的状态。CI 环境里卡死比报错更让人头疼因为它会导致任务超时却不告诉你原因。加上这一行Git 会立刻报错提示缺少凭据方便快速定位。4.3 代理与安全网关也可能背锅最后必须提一类最容易被忽略的情况代理干扰。公司内网经常有统一出口代理或安全扫描网关它们会拦截 HTTP 流量做审计有时会改动 Authorization 请求头。于是客户端明明发送了正确的凭据经过中间层后服务端收到的是残缺或编码错乱的信息返回 Access denied。这种问题的特征是同一套凭据在家里网络能正常使用在公司网络就报错。遇到这种情况先做个交叉验证git config --global --unset http.proxy git config --global --unset https.proxy然后重新试一次git ls-remote https://git.example.com/组名/仓库.git。如果不再报 Access denied说明就是代理的问题。解决方式要么在 Git 配置里正确设置代理地址和认证要么在环境变量里配置NO_PROXY把内网平台地址排除在代理之外。与之相似的还有平台使用自签名证书或内部 CA 证书的情况。Git 默认会校验证书链对不受信任的证书直接报 SSL 错误被设置成忽略证书校验后又可能在认证阶段出现各种奇奇怪怪的问题包括 Access denied。严谨的解决方案是把内部 CA 证书导入系统的信任链然后在 Git 里显式指定git config --global http.sslCAInfo /路径/你的CA证书.crt这一通操作下来基本能把环境因素排干净。5. 一次搞定面向未来的认证配置与团队协作规范5.1 从源头减少 Access denied 的团队约定个人踩坑能解决一时问题但一个团队里如果人人都在自己的电脑上反复折腾认证效率损失相当可观。我在团队里推行过几条简单的约定效果显著所有项目统一使用 SSH 密钥认证不用 HTTPS 推代码新成员入职时第一件事就是生成密钥、添加公钥、clone 仓库验证连通性如果必须用 HTTPS统一使用个人访问令牌并设置一年或半年的过期提醒技术文档和 README 里严禁出现包含账号密码或 Token 的远程地址一旦发现立即撤销 Token密码或 Token 变更后同步检查自己的电脑凭据缓存特别是 Windows 用户建立一份认证问题排查小抄放在团队 Wiki 里内容就是这篇文章的浓缩版。这些约定不一定能消灭所有认证问题但可以把报错频率降到很低。新同事不会再对着 Access denied 干瞪眼运维同事也不用反复远程帮人删缓存。5.2 我建议的日常命令与逃生工具清单最后分享一份我常年驻留在终端笔记里的命令清单。当 Access denied 再次出现时按顺序执行基本不慌# 1. 查看当前远程地址 git remote -v # 2. 直接验证凭据是否有用换成你自己的 URL curl -u 用户名:密码 https://git.example.com/api/v3/user # 3. 查看 Git 会使用哪个凭据助手 git config --global --get credential.helper # 4. 清空缓存文件 / 删除凭据条目 rm -f ~/.git-credentials cmdkey /delete:git:https://git.example.com # Windows # 5. 换一种认证方式测试远端可达性 git ls-remote https://git.example.com/组名/仓库.git # 6. CI 环境快速失败 export GIT_TERMINAL_PROMPT0这套清单覆盖了凭据有效性和缓存清理两个核心环节剩下的就是去平台页面检查权限与 Token 作用域。如果这些都做完了仍然报错再考虑代理、证书、防火墙等环境因素。就我个人经验而言Access denied 这个报错最大的特点不是难而是乱。它把密码错误、token 权限不足、凭据缓存、权限变更、中间层干扰全都装进了同一个报错文案里导致很多人被迫在多个方向上同时碰运气。但只要理解了 HTTP Basic 认证的转发链路再按先验凭据、再清缓存、后查权限、最后查环境的顺序操作绝大多数情况都能在十分钟内解决。我自己踩过最惨的一次是被平台强制改密后Windows 凭据管理器里还躺着旧密码连续两个小时以为是账号被封最后发现只是 CtrlS 前忘了下一步。从那以后我养成了一个习惯任何密码类变更后第一件事先清 Git 凭据缓存再执行第一次拉取。这个习惯保住了我后面很多个下午的平静心情。