1. 这个报错到底在说什么
如果你在用 TortoiseGit 往远端仓库推送代码时，突然弹出一行英文提示：Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.，别慌，这不是你的 Git 装坏了，也不是仓库地址写错了，而是远端代码托管平台在几年前就彻底停掉了“账号密码直接认证”这条老路。简单说，以前你输入用户名和登录密码就能推代码，现在这条路被堵死了，平台要求你改用一种叫个人访问令牌（Personal Access Token，简称 PAT）的东西来证明身份。
这个变化影响的范围其实挺大。很多刚接触 Git 的朋友，或者虽然用了几年但一直靠 TortoiseGit 图形界面“点点点”完成推送的人，第一次遇到这个提示往往会懵：我密码没输错啊，怎么就不让推了？原因就在于，TortoiseGit 默认走的还是 HTTPS 协议，而 HTTPS 协议下的身份认证方式，从 2021 年 8 月 13 日起，主流托管平台就不再接受账户登录密码了。你输入的密码再正确，服务器也会直接拒绝，因为它压根不再校验密码，而是校验令牌。
这篇文章就是写给正在被这个提示卡住的你。不管你是刚学会用 TortoiseGit 提交代码的新手，还是习惯了老流程、突然发现推不上去的老手，我都会把这件事的来龙去脉、令牌的申请方式、TortoiseGit 里的具体配置步骤，以及我实际踩过的坑，一条一条讲清楚。看完之后，你不仅能解决眼前这个报错，还能顺带把 Git 的认证体系理解个七七八八，以后再遇到类似问题，自己就能判断该往哪个方向排查。
需要先明确一点：这个提示本身不是错误，而是一条“通知”。它告诉你旧的认证方式已经下线，请换用令牌。所以解决思路很直接——去平台生成一个令牌，然后用令牌替代原来的密码。听起来简单，但实际操作里，令牌的权限怎么勾、TortoiseGit 的凭据存在哪、为什么改了令牌还是提示失败，这些细节才是真正让人头疼的地方。下面我按自己的实操顺序，一步步拆开讲。
2. 为什么密码认证会被彻底移除
2.1 从“账号密码”到“令牌”的底层逻辑
要理解这个变化，得先搞清楚 HTTPS 推送代码时，认证到底发生在哪一层。当你用 TortoiseGit 推送代码，它底层调用的是 Git 的push命令，走的是 HTTPS 协议。这个过程中，客户端需要向服务器证明“我是这个仓库的有权限用户”。最早的方案很简单：把用户名和密码一起发过去，服务器比对数据库，匹配就放行。
问题在于，密码这个东西一旦泄露，后果是全局性的。你的账号密码可能同时用于登录网页、管理仓库、修改资料，甚至关联其他服务。而且很多人的密码强度不够，或者在不同平台重复使用，一旦某个环节被撞库，整个账号就沦陷了。更麻烦的是，密码认证过程中，有些客户端会把密码明文缓存在本地，或者在不安全的网络环境里传输，风险很高。
令牌的思路则完全不同。它是一串由平台生成的随机字符串，你可以给它设定有效期和权限范围。比如你只让它有读代码的权限，那即使这串令牌泄露了，别人也只能读，不能改、不能删、不能碰你的账号设置。而且令牌可以随时吊销，吊销之后立刻失效，不像密码改了还会影响其他登录场景。这种“最小权限 + 可撤销”的机制，安全性比密码高出一个量级。
所以平台移除密码认证，本质上是在强制用户升级到更安全的认证方式。这不是某一家平台的任性行为，而是整个行业在安全实践上的共识。你可能会觉得麻烦，但从账号安全角度看，这个方向是对的。
2.2 为什么偏偏是 2021 年 8 月 13 日
这个日期是主流托管平台统一执行的时间点。在此之前，平台其实已经预告了很久，给了开发者充足的迁移时间。选择这个时间，一方面是因为令牌机制已经成熟，工具链支持也到位了；另一方面，当时针对开发者账号的攻击事件频发，平台需要尽快堵住密码认证这个最大的风险口。
对普通用户来说，这个日期意味着一个分水岭：在此之前，你用密码还能推代码；在此之后，密码通道彻底关闭。所以如果你是在 2021 年 8 月 13 日之后才开始用 TortoiseGit，或者之前一直没推过代码，那你大概率会直接撞上这个提示。这不是你的操作有问题，而是时代变了。
2.3 TortoiseGit 在这个变化里扮演什么角色
TortoiseGit 是一个 Git 的图形化客户端，它本身不负责认证逻辑，认证是底层 Git 和远端服务器之间的事。但 TortoiseGit 会帮你缓存凭据，方便你下次不用重复输入。问题就出在这个缓存上：如果你之前用密码认证成功过，TortoiseGit 会把密码存起来；现在密码失效了，它还在拿旧密码去试，自然会被拒绝。
所以解决这个报错，核心不是改 TortoiseGit 的设置，而是更新它使用的凭据。把旧的密码换成新的令牌，让 TortoiseGit 用令牌去认证。理解这一点，后面的操作就顺了。
3. 申请个人访问令牌的完整流程
3.1 令牌在哪里申请
令牌的申请入口在托管平台的网页端，不在 TortoiseGit 里。你需要先登录你的代码托管平台账号，找到“设置”或者“开发者设置”相关的页面，里面会有一个“个人访问令牌”或“Personal Access Token”的选项。不同平台的菜单名称可能略有差异，但大体路径是：头像菜单 → 设置 → 开发者设置 → 个人访问令牌 → 生成新令牌。
这里要提醒一句：令牌只在生成的时候显示一次，页面刷新后就再也看不到了。所以生成之后，务必立刻复制保存到安全的地方。我见过不少人生成完随手关掉页面，结果又要重新生成一遍，白白浪费时间。
3.2 令牌的权限该怎么勾
这是最容易出错的地方。令牌的权限勾选直接决定了你能做什么操作。如果你只是要推送代码，那至少需要仓库读写权限。具体来说，通常包括：
- 仓库内容读取和写入
- 提交状态更新
- 拉取请求创建和更新（如果你用合并请求流程）
如果你勾少了，推送时可能会提示权限不足；勾多了，又增加了令牌泄露后的风险。我的建议是：按需勾选，够用就行。如果你只是个人项目推代码，勾上仓库读写基本就够了。如果你还涉及流水线、包管理等操作，再按需增加对应权限。
另外，令牌的有效期也建议设置一个合理的值。如果是长期使用的开发机，可以设长一点，比如 90 天或一年；如果是临时环境，设短一点更安全。到期后重新生成即可，这个成本很低。
3.3 生成令牌时的注意事项
生成令牌时，平台通常会要求你输入一个名称，用来标识这个令牌的用途。建议起一个能让你日后一眼看懂的名字，比如“办公电脑-TortoiseGit”或者“个人笔记本-代码推送”。这样万一以后要吊销某个令牌，你能快速定位到是哪个设备在用。
还有一点：有些平台在生成令牌时会要求你再次输入账号密码确认身份。这一步是正常的，输入即可。生成成功后，令牌通常是一串以特定前缀开头的长字符串，复制的时候注意不要多复制空格或换行符，否则认证会失败。
提示：令牌等同于密码，甚至比密码更敏感。不要把它写进代码里，不要提交到仓库，不要发在聊天群里。一旦泄露，立刻去平台吊销并重新生成。
4. TortoiseGit 里怎么把密码换成令牌
4.1 先清掉旧的凭据缓存
很多人换了令牌还是提示失败，根本原因就是 TortoiseGit 或者系统凭据管理器里还存着旧密码。你输入的新令牌根本没被用上，客户端还在拿旧密码去试。所以第一步不是急着推送，而是先把旧凭据清掉。
在 Windows 系统里，TortoiseGit 默认使用Windows 凭据管理器来存储凭据。你可以打开控制面板，找到“凭据管理器”，在“Windows 凭据”里找和你的代码托管平台相关的条目，把它删除。删除之后，下次推送时 TortoiseGit 会重新弹窗让你输入用户名和密码，这时候你输入令牌，它就会存新的。
如果你用的是 TortoiseGit 自带的凭据存储方式，可以在 TortoiseGit 的设置里找到“Git” → “凭据”，看看有没有缓存。不过大多数情况下，清掉 Windows 凭据管理器里的条目就够了。
4.2 推送时正确输入令牌
清掉旧凭据后，你在 TortoiseGit 里执行推送操作，它会弹出一个认证窗口，要求输入用户名和密码。这里的用户名填你的平台账号名，密码填你刚才生成的令牌。注意，密码框里填的不是你的登录密码，而是那串令牌字符串。
输入完成后，TortoiseGit 会把令牌存到凭据管理器里，下次就不用再输了。如果推送成功，说明令牌生效了。如果还是失败，先检查令牌有没有复制完整，再检查权限有没有勾对。
4.3 如果弹窗没出现怎么办
有时候你清了凭据，但推送时 TortoiseGit 不弹窗，直接报错。这种情况通常是凭据没有被完全清除，或者 TortoiseGit 用了其他缓存机制。你可以尝试以下操作：
- 重启 TortoiseGit 或者重启电脑，确保缓存刷新
- 在 TortoiseGit 设置里找到“网络”选项，检查认证方式
- 手动在凭据管理器里再确认一遍，确保没有残留条目
还有一种可能是你的仓库地址里带了用户名，比如https://username@platform.com/repo.git。这种写法有时会干扰认证流程，建议把地址改成不带用户名的标准形式，让 TortoiseGit 自己弹窗询问。
5. 常见问题与排查技巧实录
5.1 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 提示密码认证已移除 | 用了登录密码而非令牌 | 生成令牌，用令牌替代密码 |
| 输入令牌后仍提示失败 | 旧凭据未清除 | 清空凭据管理器中的相关条目 |
| 令牌复制后认证失败 | 复制时带了空格或换行 | 重新复制，确保字符串完整 |
| 推送提示权限不足 | 令牌权限勾选不够 | 重新生成令牌，勾选仓库读写权限 |
| 弹窗不出现直接报错 | 凭据缓存未刷新 | 重启客户端或电脑，检查凭据管理器 |
| 令牌过期后推送失败 | 令牌有效期已到 | 重新生成令牌并更新凭据 |
5.2 我踩过的几个坑
第一个坑是令牌权限勾少了。有一次我只勾了读取权限，结果推送时一直提示权限不足，排查了半天才发现是令牌的问题。后来重新生成，勾上写入权限，立刻就通了。所以如果你推送失败但认证通过了，优先检查令牌权限。
第二个坑是凭据管理器里有多个条目。有些平台会在凭据管理器里存好几条记录，比如网页登录一条、Git 操作一条。我只删了其中一条，结果推送时还是拿旧的去试。后来把所有相关条目都删掉，才彻底解决。所以清理凭据时，宁可多删几条，别漏。
第三个坑是令牌过期没注意。令牌设了 30 天有效期，到期后推送突然失败，一开始还以为是网络问题。后来去平台一看，令牌已经过期了。重新生成一个就行。建议给令牌设个提醒，或者设长一点的有效期，减少这种意外。
5.3 一个容易被忽略的细节
TortoiseGit 的版本也会影响认证流程。老版本的 TortoiseGit 可能对令牌的支持不够完善，弹窗逻辑或者凭据存储方式和新版本有差异。如果你用的是很老的版本，建议先升级到较新的稳定版，再按上面的步骤操作。升级本身不复杂，去官网下载安装包覆盖安装即可，配置一般会保留。
另外，如果你同时装了 Git for Windows 和 TortoiseGit，两者可能共用凭据管理器。这种情况下，清理凭据时要确保两边都不残留旧密码，否则还是可能互相干扰。
6. 从根上理解 Git 的认证方式
6.1 HTTPS 和 SSH 两条路
Git 推送代码主要有两种协议：HTTPS 和 SSH。HTTPS 就是你用 TortoiseGit 默认走的方式，需要用户名和令牌（以前是密码）。SSH 则是通过密钥对认证，你生成一对公钥和私钥，把公钥传到平台，私钥留在本地，推送时自动完成认证，不需要每次输入令牌。
两种方式各有优劣。HTTPS 的好处是配置简单，走标准端口，不容易被网络环境限制；SSH 的好处是认证自动化，不用管令牌过期，但需要生成密钥并配置，初次设置稍微麻烦一点。如果你经常被令牌过期困扰，可以考虑换成 SSH 方式，一劳永逸。
6.2 令牌和 SSH 密钥怎么选
如果你只是偶尔推代码，或者在公司电脑上不方便生成密钥，那用令牌就够了。令牌的申请和更新都很简单，几分钟搞定。如果你每天都要推代码，而且希望完全免去认证的烦恼，那 SSH 密钥更合适。生成一次，长期有效，不用记令牌，也不用担心过期。
不过 SSH 密钥也有自己的注意事项：私钥文件不能泄露，最好设置一个密码短语保护；公钥要正确上传到平台；如果换了电脑，需要重新生成或迁移密钥。这些细节在初次配置时稍微花点时间，但后续会省很多事。
6.3 为什么理解认证方式很重要
很多人遇到报错就急着搜“怎么解决”，照着步骤点一遍，问题暂时没了，但下次换个场景又懵了。根本原因是对认证机制没有整体认知。你知道了 HTTPS 用令牌、SSH 用密钥，知道了凭据存在哪里、怎么清理，知道了权限和有效期的作用，那以后再遇到类似问题，你就能自己判断是哪个环节出了岔子，而不是盲目试错。
这也是我写这篇内容的初衷：不只是告诉你点哪个按钮，而是让你理解背后的逻辑。这样你不仅解决了眼前的报错，还顺带提升了对 Git 工具链的掌控力。
7. 几个提升效率的实操建议
7.1 给令牌设置合理的有效期和备注
令牌的有效期不是越长越好，也不是越短越好。太长，泄露风险高；太短，频繁重新生成也麻烦。我的习惯是：个人常用设备设 90 天，临时环境设 7 天，并且每次生成时都写清楚用途备注。这样到期前平台通常会发提醒，你提前更新就行，不会突然中断工作。
备注也很重要。如果你有多个令牌，分别用于不同设备或不同用途，备注能帮你快速识别。比如“台式机-推送专用”“笔记本-全权限”“CI 环境-只读”，一看就明白。吊销的时候也不会误伤其他设备。
7.2 定期清理不再使用的令牌
和密码一样，令牌也应该定期清理。换了电脑、换了工作环境，旧设备上的令牌如果不再使用，建议去平台吊销掉。这样即使旧设备丢失或被他人使用，也不会影响你的仓库安全。清理的频率不用很高，半年检查一次就够了。
7.3 用凭据管理器统一管理
Windows 的凭据管理器其实挺好用的，它不仅能存 Git 凭据，还能存其他应用的凭据。你可以把它当成一个统一的凭据中心，定期查看里面存了哪些条目，清理不再需要的。这样既安全，又方便排查问题。如果你用的是 macOS 或 Linux，也有对应的凭据管理工具，思路是一样的。
7.4 遇到问题先看提示原文
最后分享一个习惯：遇到报错，先别急着搜解决方案，把提示原文读一遍。很多时候，提示里已经写清楚了原因和方向。比如这个“Support for password authentication was removed”，它明确告诉你密码认证被移除了，请用令牌。你只要顺着这个方向去查令牌怎么申请、怎么配置，就能解决。盲目搜索反而容易被过时或不相关的信息带偏。
8. 我个人在实际操作中的体会
这个报错我前后遇到过好几次，每次都是在不同环境、不同设备上。最开始我也觉得麻烦，心想为什么不能继续用密码。但后来想明白了：密码认证的时代确实该结束了，令牌和密钥才是更安全的做法。虽然初次配置多花了几分钟，但后续推送代码时反而更省心，因为不用担心密码泄露，也不用频繁改密码。
我现在的习惯是：新设备第一次推送时，直接生成一个专用令牌，设好有效期和权限，用完就吊销。如果是长期使用的设备，就配置 SSH 密钥，彻底免去认证烦恼。两种方式配合使用，基本覆盖了所有场景。
如果你现在正被这个提示卡住，按上面的步骤走一遍，应该十分钟内就能解决。解决之后，建议花点时间理解一下令牌和密钥的区别，以后遇到类似问题就不会再慌了。代码推送这件事，认证方式会不断演进，但核心逻辑不变：证明你是你，并且只给你需要的权限。理解了这个，什么报错都能从容应对。
