1. 这条报错到底在说什么如果你在命令行里执行git push、git clone或者git pull突然蹦出一行红字remote: Support for password authentication was removed on August 13, 2021. remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication. fatal: Authentication failed for https://github.com/xxx/xxx.git/第一反应大概率是“我密码没输错啊”。但问题恰恰不在密码对不对而在于你用的这种认证方式本身已经被平台停用了。简单说从 2021 年 8 月 13 日起用账号密码直接做 Git 的 HTTPS 认证这条路被彻底关掉了。你输入的密码哪怕完全正确服务器也会直接拒绝。这条报错的核心信息可以拆成三层来理解。第一层是“password authentication was removed”意思是基于账号密码的认证方式被移除第二层是时间点“August 13, 2021”说明这是一个已经生效很久的变更不是临时故障第三层是“currently recommended modes of authentication”提示你应该换用官方推荐的认证方式。很多人会误以为这是网络问题或者仓库权限问题反复重试、换网络、清缓存结果毫无用处。实际上它跟网络无关跟仓库是否存在也无关纯粹是认证协议层面的变化。你要做的是把“用密码认证”换成“用令牌或密钥认证”。这篇文章适合两类人看一类是刚接触 Git、第一次遇到这个报错完全懵的新手另一类是用了很多年 Git习惯性输密码突然某天发现推不上去的老手。我会把背后的原因、几种可行的替代方案、每种方案的完整操作步骤以及我自己踩过的坑都讲清楚让你看完就能直接动手解决。2. 为什么平台要砍掉密码认证要理解这个变更得先搞清楚 Git 通过 HTTPS 推送时认证过程到底发生了什么。当你执行git push到一个 HTTPS 地址时Git 会向服务器发起请求服务器返回一个 401 状态码要求认证然后 Git 会提示你输入用户名和密码把这两样东西发回去。问题就出在这个“密码”上。传统的账号密码认证有几个致命缺陷。第一密码是长期有效的静态凭证。一旦泄露攻击者可以长期使用而你很难察觉。第二很多人在多个平台复用同一个密码一个地方泄露就全线沦陷。第三密码认证无法做细粒度的权限控制要么全有要么全无。第四自动化脚本里经常把密码明文写在配置文件里风险极高。平台方推动这个变更本质上是想用短期有效的令牌或非对称密钥来替代长期静态密码。令牌可以设置过期时间、可以限定权限范围、可以随时吊销密钥则根本不传输秘密本身只传输签名。这两种方式在安全性上都远胜于密码。注意这个变更只影响 HTTPS 协议的认证方式不影响 SSH 协议。如果你一直用的是 SSH 地址gitgithub.com:xxx/xxx.git那这条报错跟你无关。从行业趋势看这不是某一家平台的特例。主流的代码托管平台基本都在往令牌化和密钥化方向走。所以学会用令牌和 SSH 密钥不只是解决眼前这一个报错而是掌握了一套通用的、面向未来的认证方式。下面我会把两种主流方案都讲透你可以根据自己的使用场景选一种。3. 方案一用个人访问令牌替代密码个人访问令牌Personal Access Token简称 PAT是最接近原来“输密码”体验的方案。你只需要生成一个令牌字符串然后在需要输密码的地方把它粘贴进去就行。改动最小上手最快。3.1 生成令牌的完整步骤登录你的代码托管平台账号进入设置页面。不同平台入口略有差异但大体路径是头像菜单 → Settings → Developer settings → Personal access tokens。找到创建令牌的按钮点击生成。创建时最关键的是权限范围scopes的选择。这里有个常见误区很多人图省事直接勾选全部权限这是很不安全的做法。正确的思路是按需授权。如果你只是要推送代码到自己的仓库勾选repo相关的读写权限就够了如果你还要操作工作流再额外勾选workflow。权限给多了令牌一旦泄露损失面会大很多。生成之后令牌只会显示一次。务必立刻复制保存页面刷新后就再也看不到了。如果没保存只能删掉重新生成。我建议把它存到一个密码管理器里而不是随手贴在某个文本文件里。3.2 令牌在命令行里怎么用生成令牌后回到命令行重新执行git push。当提示输入用户名时输入你的账号名当提示输入密码时粘贴令牌而不是你的登录密码。这样就能正常推送了。但每次都要手动输入很麻烦。有两种方式可以免去重复输入。第一种是让 Git 记住凭证# 开启凭证缓存默认缓存 15 分钟 git config --global credential.helper cache # 或者设置更长的缓存时间单位是秒 git config --global credential.helper cache --timeout3600第二种是使用系统级的凭证存储把凭证持久化保存# macOS 使用钥匙串 git config --global credential.helper osxkeychain # Windows 使用凭证管理器 git config --global credential.helper manager # Linux 使用 libsecret git config --global credential.helper libsecret设置好之后第一次输入令牌后续就不用再输了。这里有个坑要提醒如果你之前输错过密码凭证可能已经被错误地缓存了。这时候需要先清除旧凭证再重新输入。macOS 上可以在钥匙串访问里搜索对应主机名删除Windows 上在凭证管理器里删除Linux 上执行git credential-cache exit清空缓存。3.3 令牌方案适合谁不适合谁令牌方案最大的优点是改动小、上手快特别适合临时用一下、或者不熟悉密钥配置的人。但它也有明显的短板。令牌本质上还是一个“秘密字符串”存在泄露风险令牌有有效期到期后需要重新生成和替换如果你在多台机器上工作每台都要配置一遍。还有一个容易被忽略的问题如果你在 CI/CD 流水线或者自动化脚本里用令牌一定要用环境变量注入绝对不要把令牌硬编码在脚本文件里提交到仓库。我见过有人把令牌直接写在.git/config的 URL 里结果仓库一公开令牌就暴露了。这种低级错误造成的损失往往很严重。4. 方案二配置 SSH 密钥一劳永逸如果你长期用 Git我强烈建议直接上 SSH 密钥。配置一次之后所有操作都不用再输任何凭证而且安全性比令牌更高因为私钥永远不会离开你的机器。4.1 生成密钥对时那几个关键选择打开终端执行生成命令ssh-keygen -t ed25519 -C your_emailexample.com这里有几个参数值得说明。-t ed25519指定密钥类型。为什么推荐 ed25519 而不是传统的 RSA因为 ed25519 在更短的密钥长度下提供了同等甚至更高的安全性生成和验证速度也更快。如果你因为某些老系统兼容性原因必须用 RSA那至少要用 4096 位ssh-keygen -t rsa -b 4096。-C后面跟的是注释通常填邮箱方便你在多把密钥中辨认这一把是谁的。这个注释不影响功能纯粹是给人看的。执行后系统会问你把密钥存到哪里默认是~/.ssh/id_ed25519。如果你只有一把密钥直接用默认路径就行。如果你需要管理多把密钥比如工作一把、个人一把那就起个有意义的名字比如~/.ssh/id_ed25519_work。接下来会问你要不要设置密码短语passphrase。设置密码短语相当于给私钥再加一层保护即使私钥文件被盗没有密码短语也用不了。代价是每次使用都要输入一次。你可以配合 ssh-agent 来避免重复输入。4.2 把公钥交给平台生成完成后你会得到两个文件id_ed25519私钥和id_ed25519.pub公钥。私钥绝对不能给任何人公钥才是你要上传的。查看公钥内容cat ~/.ssh/id_ed25519.pub复制输出的整行内容进入平台的 SSH 密钥设置页面通常在 Settings → SSH and GPG keys点击添加把公钥粘贴进去起个名字保存。这里有个细节粘贴时一定要完整复制包括开头的ssh-ed25519和结尾的注释部分。少一个字符都会导致认证失败。另外公钥可以随便分发它本来就是公开的私钥则要严格保密权限建议设置为600chmod 600 ~/.ssh/id_ed255194.3 验证配置是否真的生效配置完别急着推送先用一条命令验证ssh -T gitgithub.com如果看到类似“Hi xxx! Youve successfully authenticated”的提示说明配置成功。如果提示权限被拒绝或者连接超时那就要排查了。验证通过后还需要确认你的仓库远程地址用的是 SSH 格式而不是 HTTPS 格式。查看当前地址git remote -v如果显示的是https://...开头需要改成 SSH 格式git remote set-url origin gitgithub.com:xxx/xxx.git改完之后再推送就不会再出现密码认证的报错了。4.4 多密钥场景下的配置技巧如果你有多把密钥需要告诉 SSH 在连接不同主机时用哪把密钥。编辑~/.ssh/config文件Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal配置好之后克隆仓库时把主机名替换成你定义的别名即可比如git clone gitgithub-work:xxx/xxx.git。这样 SSH 就会自动选用对应的密钥。这个技巧在多账号场景下非常实用能避免密钥用错导致的认证失败。5. 排查链路为什么我换了方式还是报错很多人换了令牌或配了密钥结果还是报同样的错。这时候不要慌按下面的链路一步步排查基本都能定位到问题。5.1 先确认远程地址到底是什么协议第一步永远是看远程地址git remote -v如果输出是https://开头那说明你还在用 HTTPS 协议。这时候即使你配好了 SSH 密钥也没用因为 SSH 密钥只对 SSH 协议生效。解决办法就是上面说的git remote set-url改成 SSH 地址。反过来如果你用的是 HTTPS 协议那就必须用令牌SSH 密钥帮不上忙。协议和认证方式是绑定的不能混用。5.2 检查凭证是不是被错误缓存了如果你之前输错过密码系统可能把错误的凭证缓存起来了导致你后面输对了也没用。这时候需要清除缓存。不同系统的清除方式不同系统清除方式macOS打开钥匙串访问搜索主机名删除对应条目Windows控制面板 → 凭证管理器 → 删除对应条目Linux执行git credential-cache exit或删除~/.git-credentials清除后重新执行推送系统会重新提示输入凭证这时候再输入正确的令牌。5.3 SSH 连接失败的常见原因如果用的是 SSH 协议验证命令报错常见原因有这么几个。第一是公钥没上传成功回平台设置页面确认一下。第二是私钥权限太开放SSH 会拒绝使用权限过松的私钥执行chmod 600修正。第三是 ssh-agent 没有加载私钥执行ssh-add ~/.ssh/id_ed25519手动加载。第四是配置文件写错了检查~/.ssh/config里的主机名和密钥路径是否正确。还有一个比较隐蔽的问题某些网络环境下 SSH 的 22 端口可能不通。这时候可以测试一下连接如果确认是端口问题可以改用 HTTPS 加令牌的方案或者查询平台是否提供其他端口的 SSH 接入方式。5.4 一个容易被忽略的细节用户名用 HTTPS 加令牌时用户名的填写也有讲究。有些平台要求填账号名有些场景下填git也可以。如果你不确定就填你的账号名。填错了同样会认证失败而且报错信息可能还是那条“密码认证被移除”容易误导你以为令牌有问题。6. 我踩过的几个坑和实用建议讲完方案和排查分享几个我自己实际踩过的坑都是文档里不会写的。第一个坑是令牌权限给太多。早期我图省事直接全选后来意识到这等于把整个账号的控制权交出去了。现在我的做法是每个用途单独生成一个令牌比如一个专门用于本地推送一个专门用于某台服务器上的自动部署权限各自最小化。这样即使某个令牌泄露影响范围也可控而且能快速定位是哪个环节出的问题。第二个坑是密钥注释写得太随意。我一开始所有密钥的注释都填的同一个邮箱结果机器上攒了五六把密钥后完全分不清哪把是哪把。后来改成“用途-设备-日期”的格式比如deploy-server-a-202401管理起来清晰多了。这个习惯在多密钥环境下特别重要。第三个坑是忘了更新远程地址。我配好了 SSH 密钥验证也通过了但推送还是报错折腾了半天才发现仓库的远程地址还是 HTTPS 的。所以记住那个顺序先确认协议再确认认证方式最后才怀疑凭证本身。第四个坑是在自动化脚本里硬编码令牌。这个前面提过但值得再强调一次。正确做法是用环境变量或者平台的密钥管理功能注入脚本里只引用变量名。如果令牌不小心提交到了仓库第一件事是立刻去平台吊销它然后再清理历史记录。吊销永远比清理更紧急因为清理需要时间而令牌在泄露的那一刻就已经不安全了。最后一个建议如果你经常换机器或者用多台设备SSH 密钥方案会让你省心很多。把私钥安全地同步到各台设备比如通过加密的密码管理器或者每台设备生成独立的密钥分别上传公钥都比每次输令牌要方便。令牌适合临时场景密钥适合长期使用根据自己的实际情况选就行。这套认证方式的变更本质上是一次安全升级虽然短期内给习惯了输密码的人带来了麻烦但换来的是更可控、更安全的凭证管理。花半小时把 SSH 密钥配好之后几年都不用再为这个问题操心这笔时间投入很划算。