git使用token代替密码认证的方法【教程】-git-PHP中文网

github自2021年8月13日起全面停用https账号密码认证，必须使用personal access token（pat）替代；token需正确配置repo等权限、匹配https协议url，并清除旧凭据缓存方可生效。

git使用token代替密码认证的方法【教程】

GitHub 和 GitLab 已全面停用 HTTPS 账号密码认证，直接输密码一定会失败；必须用 Token 替代，且 Token 不是“随便生成一个就行”，权限、存储方式、URL 协议三者不匹配，照样报错。

git push 报 remote: Support for password authentication was removed 错误

这是最典型的信号：你正试图用账号密码走 HTTPS 协议推送到 GitHub 或 GitLab。2021 年 8 月 13 日起，GitHub 彻底关闭该路径；GitLab 后续也收紧策略（尤其私有实例和 SSO 环境）。错误里明确提示要换 Personal Access Token，但很多人卡在“输完 Token 还是被拒”。

常见原因包括：

生成 Token 时没勾选 repo（GitHub）或 read_repository/write_repository（GitLab）权限
远程 URL 仍是 SSH 格式（如 git@gitlab.com:user/proj.git），而 Token 只对 HTTPS 有效
系统缓存了旧密码，没触发新 Token 输入流程（git push 直接失败，根本不问你用户名密码）

验证是否命中缓存问题：运行 git credential reject，然后输入：

protocol=https
host=github.com
username=your_username

回车后再次 git push，就会重新弹出用户名/密码提示——这时再输用户名 + Token。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

生成 GitHub/GitLab Token 时必须选对 scope

Token 权限不是“越全越好”，但关键 scope 漏掉一个就完全不可用。

GitHub：至少勾选 repo（含私有库读写）、workflow（如果用 GitHub Actions）；user 和 gist 按需
GitLab：read_repository（克隆）、write_repository（推送）是基础；CI 场景还需 api；项目级 Token 在 Settings → Access Tokens 里创建，权限粒度更细
注意有效期：GitHub classic token 默认永不过期，但建议设为 90 天；GitLab 默认 1 年，生产环境建议缩至 30–60 天

生成后页面只显示一次，格式类似 ghp_aBcDeFgHiJkLmNoPqRsTuVwXyZ123456789（GitHub）或 glpat-xYzAbCdEfGhIjKlMnOpQrStUvWxYz123456789（GitLab），复制即用，关页即丢。

HTTPS 远程地址 + 凭据缓存配置才真正“一劳永逸”

Token 本身是一次性字符串，要让它长期生效，得靠 Git 的凭据机制配合 HTTPS URL。

先确认远程地址是 HTTPS 格式：运行 git remote get-url origin，应返回类似 https://github.com/username/repo.git；如果不是，用 git remote set-url origin https://github.com/username/repo.git 切换
启用凭据存储（明文）：git config --global credential.helper store；首次 git push 时输入用户名 + Token，之后自动复用
更安全的替代：git config --global credential.helper cache（内存缓存，默认 15 分钟），或 macOS 上用 osxkeychain、Windows 上用 manager-core（需安装 Git for Windows 最新版）
清除旧凭据：macOS 打开 Keychain Access 搜索 github.com，删掉对应条目；Windows 在“凭据管理器→Windows 凭据”里找 git:https://github.com

为什么推荐 SSH 而不是 Token + HTTPS？

Token + HTTPS 是“能用”，SSH 是“该用”。区别不在难易，而在本质：

Token 是密码的替代品，仍属“共享凭证”，一旦泄露，攻击者可任意操作所有授权仓库；SSH 私钥不出设备，公钥只用于验证，无法反向推导
多账号场景下，HTTPS 凭据只能存一份用户名+Token，切账号必须手动删缓存；SSH 可通过 ~/.ssh/config 绑定不同 Host 到不同密钥，git clone git@work:org/repo.git 自动路由
GitLab/GitHub 都支持 SSH，但部分企业 Git 实例（如自建 Gitea）可能禁用 SSH；此时 Token + HTTPS 是唯一选择

真正容易被忽略的是：很多人生成了 Token、改了 URL、也配了 credential.helper，却忘了检查 Git 客户端版本——低于 2.29 的 Git 对某些 Token 格式兼容性差，升级到最新版可避开一堆隐性坑。