很多人第一次接触Gitee码云的仓库认证都是在某次git push报错中开始的。最常见的一类报错是Incorrect username or password ( access token )。更迷惑的是你明明已经把公钥配到Gitee后台了甚至为了保险还重新生成了一遍公钥推送时照样弹这行提示。这篇文章就把Gitee公钥的设置、修改以及这个Access Token报错背后的认证机制一次讲透附上我踩过几次坑后的排查链路给还没理顺这套逻辑的同学一个可以直接照着做的清单。这个内容适合所有用Gitee托管代码的人尤其是刚入坑、对HTTPS和SSH两条认证通道区分不清的新手以及需要在多台电脑、多个账号之间反复切换公钥的日常用户。老手也可以重点看第4章的排查流程里面有些细节是常规教程不会写的。1. Incorrect username or password ( access token )到底在拦截谁1.1 别急着改公钥先认清这行报错属于哪个认证通道这个报错绝大多数时候出现在你使用HTTPS 地址连接仓库的时候。Gitee 的 HTTPS 远程地址长这样https://gitee.com/你的用户名/仓库名.git而 SSH 地址则是gitgitee.com:你的用户名/仓库名.git当git remote -v里显示的是 HTTPS 开头Git 就会通过 HTTPS 协议去访问服务器此时服务器要求你提交用户名密码或用户名私人令牌这样的明文凭据。只要用户名不对、密码不对、令牌过期、令牌权限不足服务端统一返回这一行Incorrect username or password ( access token )这里的关键点在于公钥认证走的是 SSH 通道HTTPS 认证完全不看公钥。这两套认证体系互相独立就像银行卡和门禁卡——你在公司门禁录了指纹不代表去 ATM 取款时可以不输银行卡密码。所以每次有人问我我公钥都配了为什么还报这个错我第一句话都是先让他执行git remote -v看看到底走的是哪个通道。1.2 SSH 和 HTTPS两条通道的认证逻辑完全不同SSH 认证的核心是你有没有对应的私钥。你的本地保存私钥Gitee 后台保存公钥。git push时Git 会用私钥对服务器发来的挑战数据进行签名服务器拿公钥验签通过就确认你是这个公钥对应的所有者。整个过程不需要输入 Gitee 的登录密码。HTTPS 认证则完全不同它要求每次连接都带上用户名密码或用户名私人令牌由服务器核对这两样东西是否有效。所以报错信息认证通道常见原因Permission denied (publickey)SSH公钥未添加、私钥不匹配、ssh-agent 缓存了错误的私钥Incorrect username or password ( access token )HTTPS用户名错误、密码错误、令牌过期、令牌权限不足remote: HTTP Basic: Access deniedHTTPS凭据中的 token 无效或已删除你可以把这张表当作快速诊断工具。看到publickey就去查公钥相关配置看到username or password就去查 HTTPS 凭据而不是反复折腾公钥。1.3 最容易触发这个报错的三个现场第一个现场仓库是用 HTTPS 地址 clone 的后来你给 Gitee 后台加了公钥以为从此 push 不再需要密码。但实际上 SSH 公钥根本不会接管 HTTPS 连接push 时 Git 依旧询问用户名密码输错或输入了错误的密码就是这行报错。第二个现场换了新电脑clone 时依然用了 HTTPS 地址。系统凭据管理器里可能残留着旧账号的缓存也可能什么都没有。每次 push 都要手动输入手一抖把登录密码当令牌填进去服务端返回的还是同样一句话。第三个现场你去修改公钥刚在后台替换完顺手执行git push却被要求输密码。你以为是公钥还没生效于是又去后台删了重新加来回折腾好几轮还是没有用。这三个现场的共同点是当事人都在用 HTTPS而公钥根本管不到 HTTPS。先把这个底层认知建立起来后面所有步骤才有意义。2. 公钥的正确设置生成、添加、验证一条龙2.1 生成密钥前的两个关键决定第一个决定是算法。我现在的推荐是直接使用Ed25519ssh-keygen -t ed25519 -C 你的Gitee用户名或者备注Ed25519 生成的密钥文件更短、安全性高、计算速度快Gitee 是直接支持的。很多老教程还在用ssh-keygen -t rsa -b 4096虽然也能用但新开局真没必要再从 RSA 起步。第二个决定是给私钥设置什么样的 passphrase口令。设置了口令每次使用私钥都要输入一遍安全性更高缺点是自动化脚本会被交互式卡住。如果只是个人开发我一般建议设置一个简单的口令然后依赖 ssh-agent 帮你记住。这个口令一旦忘记就无法找回只能重新生成密钥对所以写到这一步时我会特意停顿一下提醒自己设一个能记住但不容易被猜到的别用生日和手机号。2.2 从生成到添加到后台的完整步骤生成密钥对的命令会提示你指定保存路径默认是~/.ssh/id_ed25519。如果该文件已经存在它会询问是否覆盖这一步一定要想清楚——覆盖后旧私钥就失效了你后台旧的公钥也必须同步删掉。生成完成后查看公钥cat ~/.ssh/id_ed25519.pub输出是类似ssh-ed25519 AAAA...开头的一整行。复制这一整行然后打开 Gitee 后台头像菜单 → 设置 → 安全设置 → SSH公钥标题栏随便填比如笔记本-2025公钥内容框粘贴刚才复制的整行确认添加。这里面有两个极易翻车的细节复制公钥时别带多余的空格或换行粘贴完检查一下首尾。不要手滑把私钥~/.ssh/id_ed25519的内容复制出去了。私钥是核心机密任何时候都不要发给别人也不要传到任何网盘或代码仓库。2.3 验证命令到底验证了什么设置完成之后执行ssh -T gitgitee.com首次连接会提示确认服务器指纹输入yes回车。如果看到Hi 你的用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.说明 SSH 通道已经通了。这行输出里的用户名一定要和你想访问的账号一致。如果这里验证通过但 push 依然失败那就要回到第1章的分歧点看看你是不是用了 HTTPS 地址。如果看到Permission denied (publickey)说明服务端没有认你本地提供的这把私钥。优先检查三件事后台公钥是否真的添加成功本地是否用了正确的那把私钥~/.ssh目录下是否存在多个私钥导致 Git 默认读取了错误的那个。3. 公钥的修改什么时候该动、怎么动才不会乱3.1 修改公钥其实分成好几种场景很多人一听到修改公钥第一反应就是重新执行ssh-keygen。实际上分为三类处理方式完全不同。换电脑新机器上没有旧私钥需要在新机器上生成密钥对把新公钥加到后台。如果你确定旧电脑不再使用应顺手把后台的旧公钥删除。私钥泄露不管旧私钥有没有被真正使用过都建议重建。先删除后台旧公钥再在本地删除或移走旧私钥生成新密钥对重新绑定。多账号、多平台共存同一台电脑上要管理多个 SSH 密钥让不同的平台或不同的 Gitee 账号使用不同的私钥。这种情况不叫修改叫管理核心是写好~/.ssh/config文件。3.2 修改操作的先后顺序错了会留下隐患正确的操作顺序是在 Gitee 后台删除旧公钥在本地删除或备份旧私钥生成新密钥对把新公钥添加到 Gitee 后台执行ssh -T gitgitee.com验证。为什么必须先删后台旧公钥因为一旦本地私钥泄露后台旧公钥等于一个仍然有效的后门。先删后加窗口期最多是 push 失败一两次但安全性是完整的。反过来先加新公钥再删旧公钥中间哪怕只有几分钟泄露的私钥也仍然可以冒充你操作仓库。如果你是出于安全升级的目的来做修改顺序一定不能乱。验证过后可以用这个命令确认后台指纹和本地一致ssh-keygen -l -f ~/.ssh/id_ed25519.pub再去后台对比页面显示的公钥指纹两边完全一致才算是收尾干净了。3.3 多公钥并存时最容易翻车的 config 配置如果一台电脑上要为多个平台或多个账号保存多把密钥~/.ssh/config是必须掌握的文件。下面是一份典型配置Host gitee.com HostName gitee.com User git PreferredAuthentications publickey IdentityFile ~/.ssh/id_ed25519_gitee Host gitee-work HostName gitee.com User git PreferredAuthentications publickey IdentityFile ~/.ssh/id_ed25519_gitee_work这里有个非常容易踩的坑第二个 Host 使用了别名gitee-work那么对应的远程地址也要跟着改。如果你继续用gitgitee.com:用户名/仓库.gitSSH 会去匹配Host gitee.com那段配置加载的是第一把私钥只有当你把 remote 改成gitgitee-work:用户名/仓库.git时它才会正确匹配第二段配置。很多人的报错Permission denied (publickey)就是这样产生的后台添加的是id_ed25519_gitee_work的公钥SSH 默认却读到了id_ed25519_gitee私钥身份对不上自然被拒绝。3.4 修改过后不生效问题基本出在本地缓存如果后台已经更新了公钥本地也换了新私钥但执行验证时仍旧失败优先怀疑三点ssh-agent 缓存了旧的私钥。执行ssh-add -D清空再重新添加ssh-add ~/.ssh/id_ed25519。目录~/.ssh下存在多个私钥SSH 按默认顺序读取了错误的那个。指定-i参数确认ssh -T -i ~/.ssh/id_ed25519 gitgitee.comWindows 下~/.ssh目录的权限设置不对导致 OpenSSH 拒绝加载私钥文件。可以用ssh -T -v gitgitee.com打印调试信息看Offering public key后面跟的是哪个文件路径立刻能定位问题。修改公钥本身并不复杂复杂的是你以为在改公钥其实问题根本不是公钥。4. Access Token 报错排查三层定位法4.1 第一层确认远程地址走的是 HTTPS 还是 SSH在仓库目录执行git remote -v输出如果是https://gitee.com/用户名/仓库.git那恭喜你你已经找到了 90% 的原因。当前仓库走的是 HTTPS服务器要求的是明文凭据你的公钥配置再怎么完美也帮不上忙。输出如果是gitgitee.com:用户名/仓库.git理论上不会出现Incorrect username or password ( access token )。如果仍然出现继续往下排查系统凭据管理器和全局配置是否有异常。4.2 第二层清掉系统里缓存的错误凭据HTTPS 连接时Git 会通过 credential helper 读取缓存。如果缓存里存了一个错误的用户名或过期的令牌Git 根本不会弹窗询问而是直接用旧凭据请求然后得到报错。你越是在终端里反复输入正确的密码系统越是优先相信缓存里的旧值。查看当前使用的 helpergit config --global credential.helper常见的结果是manager-coreWindows、osxkeychainmacOS或者某个基于文件的 store。对应的清理方法Windows打开控制面板 → 凭据管理器 → Windows凭据找到和gitee.com相关的条目删除。也可以用命令行cmdkey /list | findstr gitee查到对应的目标名后执行删除。macOS打开钥匙串访问搜索gitee把相关条目删除。或者用 Git 自带的删除协议printf protocolhttps\nhostgitee.com\n\n | git credential-osxkeychain eraseLinux查看~/.git-credentials删除或编辑包含gitee.com的那一行。清理结束后再次 push 会重新弹出输入框这时候再输入正确凭据即可。4.3 第三层生成私人令牌而不是继续输登录密码现在很多托管平台的 HTTPS 通道已经不允许用登录密码直接推送了即使密码正确也会被拒。Gitee 的正确做法是使用私人令牌。入口Gitee 后台 → 头像菜单 → 设置 → 安全设置 → 私人令牌 → 生成新令牌。生成时会让你勾选权限范围比如projects。这一步按你实际需求来只开需要的权限即可。生成后页面上会出现一串内容只会展示一次一定要立刻复制并保存到你自己的密码管理工具里。使用私人令牌时用户名填你的 Gitee 用户名不是昵称密码框粘贴这串令牌。如果不想每次弹框手动粘贴也可以临时放进 URL 里git remote set-url origin https://你的用户名:你的令牌gitee.com/用户名/仓库.git但我不建议长期这样写因为令牌会明文保存在仓库目录下的.git/config文件里任何能读取该文件的人都能拿走你的令牌。临时用一次没问题用过之后最好改回不带 token 的地址让 Git 重新走凭据管理。如果你并不依赖 HTTPS 的某些特性更省心的方案是把 remote 直接切成 SSHgit remote set-url origin gitgitee.com:用户名/仓库.git切换后再回到第2章验证 SSH 通道以后 push 就不需要再和账密、令牌打交道了。4.4 一个反复出现的细节改完 remote 还在弹窗有人改完set-url后push 依旧弹出账密框。90% 的情况是 remote 根本没改成功可能因为仓库路径写错或者命令执行到了错误目录下。重新执行git remote -v看一眼即可。还有一小部分情况是环境变量GIT_ASKPASS或GIT_TERMINAL_PROMPT干扰了 Git 的凭据输入流程。排查时可以强制关掉交互式提示GIT_TERMINAL_PROMPT0 git push这样 Git 不会弹出任何输入框报错会直接暴露当前真实使用的是哪个通道。这个方法在定位问题阶段非常好用。5. 公钥和 Token 的坑能避一个是一个5.1 公钥只管 SSHHTTPS 永远不爱公钥这句话你可能会觉得啰嗦但我在实际排查中十个人里至少有五个卡在这一步。他们反反复复重新生成公钥、删了再加最后发现git remote -v显示的地址是https://。先确认通道再决定折腾公钥还是折腾令牌整个排查时间能缩小到五分钟以内。5.2 换电脑后后台的旧公钥别忘了清很多人 Gitee 后台的公钥列表里躺着好几把陈年钥匙对应私钥早就不知道丢在哪块旧硬盘里了。这些公钥不会主动失效只要对应私钥落入他人之手就可能被用来冒充你操作仓库。我现在的习惯是每把公钥都用可识别的标题备注比如macbook-pro-2025、win11-desktop定期对照本地~/.ssh目录里实际存在的私钥把对不上的公钥清理掉。5.3 复制私人令牌时注意别把说明文字一起复制进去生成令牌的页面上令牌内容旁边常伴有说明文字。如果整行选中复制可能出现令牌开头多了几个字或末尾混入空格。粘贴后可以先放到记事本里看一遍前后有没有异常再填到密码框。很多Incorrect错就错在这种肉眼不容易注意的字符上。5.4 验证命令显示成功不代表你用对了账号ssh -T gitgitee.com输出Hi 用户名时那个用户名一定要仔细看。多账号场景下最常见的结果是验证通了但通的是另一个账号。 这种情况通常由 config 文件里IdentityFile指向错误导致。不要看到successfully authenticated就开心地跳过多花十秒钟确认用户名。5.5 忘掉 passphrase 只能重生成没有任何找回途径如果生成密钥时设置了 passphrase然后又把它忘了我建议直接放弃任何破解想法。唯一正确路径是删除旧私钥和旧公钥后台删除旧公钥重新生成一对新密钥再重新配置。整个过程大概五分钟远比花心思去找工具试图恢复口令更高效。5.6 Gitee 后台公钥修改是即时生效的不需要等待公钥在后台的增删基本秒级生效。如果修改之后仍然报Permission denied (publickey)问题几乎一定在本地私钥路径错了、ssh-agent 缓存了旧密钥、config 写错了对应关系。不要在后台反复删了加、加了删那样只是原地打转。我的个人习惯是所有长期维护的仓库尽量统一走 SSH 通道私钥文件放到加密备份里遇到只用 HTTPS 地址的协作场景就告诉自己公钥救不了 HTTPS私人令牌才是答案。每次被认证问题卡住先看通道再查凭据脑子里的排查链路清晰了报错也就不吓人了。
很多人第一次接触Gitee码云的仓库认证都是在某次git push报错中开始的。最常见的一类报错是Incorrect username or password ( access token )。更迷惑的是你明明已经把公钥配到Gitee后台了甚至为了保险还重新生成了一遍公钥推送时照样弹这行提示。这篇文章就把Gitee公钥的设置、修改以及这个Access Token报错背后的认证机制一次讲透附上我踩过几次坑后的排查链路给还没理顺这套逻辑的同学一个可以直接照着做的清单。这个内容适合所有用Gitee托管代码的人尤其是刚入坑、对HTTPS和SSH两条认证通道区分不清的新手以及需要在多台电脑、多个账号之间反复切换公钥的日常用户。老手也可以重点看第4章的排查流程里面有些细节是常规教程不会写的。1. Incorrect username or password ( access token )到底在拦截谁1.1 别急着改公钥先认清这行报错属于哪个认证通道这个报错绝大多数时候出现在你使用HTTPS 地址连接仓库的时候。Gitee 的 HTTPS 远程地址长这样https://gitee.com/你的用户名/仓库名.git而 SSH 地址则是gitgitee.com:你的用户名/仓库名.git当git remote -v里显示的是 HTTPS 开头Git 就会通过 HTTPS 协议去访问服务器此时服务器要求你提交用户名密码或用户名私人令牌这样的明文凭据。只要用户名不对、密码不对、令牌过期、令牌权限不足服务端统一返回这一行Incorrect username or password ( access token )这里的关键点在于公钥认证走的是 SSH 通道HTTPS 认证完全不看公钥。这两套认证体系互相独立就像银行卡和门禁卡——你在公司门禁录了指纹不代表去 ATM 取款时可以不输银行卡密码。所以每次有人问我我公钥都配了为什么还报这个错我第一句话都是先让他执行git remote -v看看到底走的是哪个通道。1.2 SSH 和 HTTPS两条通道的认证逻辑完全不同SSH 认证的核心是你有没有对应的私钥。你的本地保存私钥Gitee 后台保存公钥。git push时Git 会用私钥对服务器发来的挑战数据进行签名服务器拿公钥验签通过就确认你是这个公钥对应的所有者。整个过程不需要输入 Gitee 的登录密码。HTTPS 认证则完全不同它要求每次连接都带上用户名密码或用户名私人令牌由服务器核对这两样东西是否有效。所以报错信息认证通道常见原因Permission denied (publickey)SSH公钥未添加、私钥不匹配、ssh-agent 缓存了错误的私钥Incorrect username or password ( access token )HTTPS用户名错误、密码错误、令牌过期、令牌权限不足remote: HTTP Basic: Access deniedHTTPS凭据中的 token 无效或已删除你可以把这张表当作快速诊断工具。看到publickey就去查公钥相关配置看到username or password就去查 HTTPS 凭据而不是反复折腾公钥。1.3 最容易触发这个报错的三个现场第一个现场仓库是用 HTTPS 地址 clone 的后来你给 Gitee 后台加了公钥以为从此 push 不再需要密码。但实际上 SSH 公钥根本不会接管 HTTPS 连接push 时 Git 依旧询问用户名密码输错或输入了错误的密码就是这行报错。第二个现场换了新电脑clone 时依然用了 HTTPS 地址。系统凭据管理器里可能残留着旧账号的缓存也可能什么都没有。每次 push 都要手动输入手一抖把登录密码当令牌填进去服务端返回的还是同样一句话。第三个现场你去修改公钥刚在后台替换完顺手执行git push却被要求输密码。你以为是公钥还没生效于是又去后台删了重新加来回折腾好几轮还是没有用。这三个现场的共同点是当事人都在用 HTTPS而公钥根本管不到 HTTPS。先把这个底层认知建立起来后面所有步骤才有意义。2. 公钥的正确设置生成、添加、验证一条龙2.1 生成密钥前的两个关键决定第一个决定是算法。我现在的推荐是直接使用Ed25519ssh-keygen -t ed25519 -C 你的Gitee用户名或者备注Ed25519 生成的密钥文件更短、安全性高、计算速度快Gitee 是直接支持的。很多老教程还在用ssh-keygen -t rsa -b 4096虽然也能用但新开局真没必要再从 RSA 起步。第二个决定是给私钥设置什么样的 passphrase口令。设置了口令每次使用私钥都要输入一遍安全性更高缺点是自动化脚本会被交互式卡住。如果只是个人开发我一般建议设置一个简单的口令然后依赖 ssh-agent 帮你记住。这个口令一旦忘记就无法找回只能重新生成密钥对所以写到这一步时我会特意停顿一下提醒自己设一个能记住但不容易被猜到的别用生日和手机号。2.2 从生成到添加到后台的完整步骤生成密钥对的命令会提示你指定保存路径默认是~/.ssh/id_ed25519。如果该文件已经存在它会询问是否覆盖这一步一定要想清楚——覆盖后旧私钥就失效了你后台旧的公钥也必须同步删掉。生成完成后查看公钥cat ~/.ssh/id_ed25519.pub输出是类似ssh-ed25519 AAAA...开头的一整行。复制这一整行然后打开 Gitee 后台头像菜单 → 设置 → 安全设置 → SSH公钥标题栏随便填比如笔记本-2025公钥内容框粘贴刚才复制的整行确认添加。这里面有两个极易翻车的细节复制公钥时别带多余的空格或换行粘贴完检查一下首尾。不要手滑把私钥~/.ssh/id_ed25519的内容复制出去了。私钥是核心机密任何时候都不要发给别人也不要传到任何网盘或代码仓库。2.3 验证命令到底验证了什么设置完成之后执行ssh -T gitgitee.com首次连接会提示确认服务器指纹输入yes回车。如果看到Hi 你的用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.说明 SSH 通道已经通了。这行输出里的用户名一定要和你想访问的账号一致。如果这里验证通过但 push 依然失败那就要回到第1章的分歧点看看你是不是用了 HTTPS 地址。如果看到Permission denied (publickey)说明服务端没有认你本地提供的这把私钥。优先检查三件事后台公钥是否真的添加成功本地是否用了正确的那把私钥~/.ssh目录下是否存在多个私钥导致 Git 默认读取了错误的那个。3. 公钥的修改什么时候该动、怎么动才不会乱3.1 修改公钥其实分成好几种场景很多人一听到修改公钥第一反应就是重新执行ssh-keygen。实际上分为三类处理方式完全不同。换电脑新机器上没有旧私钥需要在新机器上生成密钥对把新公钥加到后台。如果你确定旧电脑不再使用应顺手把后台的旧公钥删除。私钥泄露不管旧私钥有没有被真正使用过都建议重建。先删除后台旧公钥再在本地删除或移走旧私钥生成新密钥对重新绑定。多账号、多平台共存同一台电脑上要管理多个 SSH 密钥让不同的平台或不同的 Gitee 账号使用不同的私钥。这种情况不叫修改叫管理核心是写好~/.ssh/config文件。3.2 修改操作的先后顺序错了会留下隐患正确的操作顺序是在 Gitee 后台删除旧公钥在本地删除或备份旧私钥生成新密钥对把新公钥添加到 Gitee 后台执行ssh -T gitgitee.com验证。为什么必须先删后台旧公钥因为一旦本地私钥泄露后台旧公钥等于一个仍然有效的后门。先删后加窗口期最多是 push 失败一两次但安全性是完整的。反过来先加新公钥再删旧公钥中间哪怕只有几分钟泄露的私钥也仍然可以冒充你操作仓库。如果你是出于安全升级的目的来做修改顺序一定不能乱。验证过后可以用这个命令确认后台指纹和本地一致ssh-keygen -l -f ~/.ssh/id_ed25519.pub再去后台对比页面显示的公钥指纹两边完全一致才算是收尾干净了。3.3 多公钥并存时最容易翻车的 config 配置如果一台电脑上要为多个平台或多个账号保存多把密钥~/.ssh/config是必须掌握的文件。下面是一份典型配置Host gitee.com HostName gitee.com User git PreferredAuthentications publickey IdentityFile ~/.ssh/id_ed25519_gitee Host gitee-work HostName gitee.com User git PreferredAuthentications publickey IdentityFile ~/.ssh/id_ed25519_gitee_work这里有个非常容易踩的坑第二个 Host 使用了别名gitee-work那么对应的远程地址也要跟着改。如果你继续用gitgitee.com:用户名/仓库.gitSSH 会去匹配Host gitee.com那段配置加载的是第一把私钥只有当你把 remote 改成gitgitee-work:用户名/仓库.git时它才会正确匹配第二段配置。很多人的报错Permission denied (publickey)就是这样产生的后台添加的是id_ed25519_gitee_work的公钥SSH 默认却读到了id_ed25519_gitee私钥身份对不上自然被拒绝。3.4 修改过后不生效问题基本出在本地缓存如果后台已经更新了公钥本地也换了新私钥但执行验证时仍旧失败优先怀疑三点ssh-agent 缓存了旧的私钥。执行ssh-add -D清空再重新添加ssh-add ~/.ssh/id_ed25519。目录~/.ssh下存在多个私钥SSH 按默认顺序读取了错误的那个。指定-i参数确认ssh -T -i ~/.ssh/id_ed25519 gitgitee.comWindows 下~/.ssh目录的权限设置不对导致 OpenSSH 拒绝加载私钥文件。可以用ssh -T -v gitgitee.com打印调试信息看Offering public key后面跟的是哪个文件路径立刻能定位问题。修改公钥本身并不复杂复杂的是你以为在改公钥其实问题根本不是公钥。4. Access Token 报错排查三层定位法4.1 第一层确认远程地址走的是 HTTPS 还是 SSH在仓库目录执行git remote -v输出如果是https://gitee.com/用户名/仓库.git那恭喜你你已经找到了 90% 的原因。当前仓库走的是 HTTPS服务器要求的是明文凭据你的公钥配置再怎么完美也帮不上忙。输出如果是gitgitee.com:用户名/仓库.git理论上不会出现Incorrect username or password ( access token )。如果仍然出现继续往下排查系统凭据管理器和全局配置是否有异常。4.2 第二层清掉系统里缓存的错误凭据HTTPS 连接时Git 会通过 credential helper 读取缓存。如果缓存里存了一个错误的用户名或过期的令牌Git 根本不会弹窗询问而是直接用旧凭据请求然后得到报错。你越是在终端里反复输入正确的密码系统越是优先相信缓存里的旧值。查看当前使用的 helpergit config --global credential.helper常见的结果是manager-coreWindows、osxkeychainmacOS或者某个基于文件的 store。对应的清理方法Windows打开控制面板 → 凭据管理器 → Windows凭据找到和gitee.com相关的条目删除。也可以用命令行cmdkey /list | findstr gitee查到对应的目标名后执行删除。macOS打开钥匙串访问搜索gitee把相关条目删除。或者用 Git 自带的删除协议printf protocolhttps\nhostgitee.com\n\n | git credential-osxkeychain eraseLinux查看~/.git-credentials删除或编辑包含gitee.com的那一行。清理结束后再次 push 会重新弹出输入框这时候再输入正确凭据即可。4.3 第三层生成私人令牌而不是继续输登录密码现在很多托管平台的 HTTPS 通道已经不允许用登录密码直接推送了即使密码正确也会被拒。Gitee 的正确做法是使用私人令牌。入口Gitee 后台 → 头像菜单 → 设置 → 安全设置 → 私人令牌 → 生成新令牌。生成时会让你勾选权限范围比如projects。这一步按你实际需求来只开需要的权限即可。生成后页面上会出现一串内容只会展示一次一定要立刻复制并保存到你自己的密码管理工具里。使用私人令牌时用户名填你的 Gitee 用户名不是昵称密码框粘贴这串令牌。如果不想每次弹框手动粘贴也可以临时放进 URL 里git remote set-url origin https://你的用户名:你的令牌gitee.com/用户名/仓库.git但我不建议长期这样写因为令牌会明文保存在仓库目录下的.git/config文件里任何能读取该文件的人都能拿走你的令牌。临时用一次没问题用过之后最好改回不带 token 的地址让 Git 重新走凭据管理。如果你并不依赖 HTTPS 的某些特性更省心的方案是把 remote 直接切成 SSHgit remote set-url origin gitgitee.com:用户名/仓库.git切换后再回到第2章验证 SSH 通道以后 push 就不需要再和账密、令牌打交道了。4.4 一个反复出现的细节改完 remote 还在弹窗有人改完set-url后push 依旧弹出账密框。90% 的情况是 remote 根本没改成功可能因为仓库路径写错或者命令执行到了错误目录下。重新执行git remote -v看一眼即可。还有一小部分情况是环境变量GIT_ASKPASS或GIT_TERMINAL_PROMPT干扰了 Git 的凭据输入流程。排查时可以强制关掉交互式提示GIT_TERMINAL_PROMPT0 git push这样 Git 不会弹出任何输入框报错会直接暴露当前真实使用的是哪个通道。这个方法在定位问题阶段非常好用。5. 公钥和 Token 的坑能避一个是一个5.1 公钥只管 SSHHTTPS 永远不爱公钥这句话你可能会觉得啰嗦但我在实际排查中十个人里至少有五个卡在这一步。他们反反复复重新生成公钥、删了再加最后发现git remote -v显示的地址是https://。先确认通道再决定折腾公钥还是折腾令牌整个排查时间能缩小到五分钟以内。5.2 换电脑后后台的旧公钥别忘了清很多人 Gitee 后台的公钥列表里躺着好几把陈年钥匙对应私钥早就不知道丢在哪块旧硬盘里了。这些公钥不会主动失效只要对应私钥落入他人之手就可能被用来冒充你操作仓库。我现在的习惯是每把公钥都用可识别的标题备注比如macbook-pro-2025、win11-desktop定期对照本地~/.ssh目录里实际存在的私钥把对不上的公钥清理掉。5.3 复制私人令牌时注意别把说明文字一起复制进去生成令牌的页面上令牌内容旁边常伴有说明文字。如果整行选中复制可能出现令牌开头多了几个字或末尾混入空格。粘贴后可以先放到记事本里看一遍前后有没有异常再填到密码框。很多Incorrect错就错在这种肉眼不容易注意的字符上。5.4 验证命令显示成功不代表你用对了账号ssh -T gitgitee.com输出Hi 用户名时那个用户名一定要仔细看。多账号场景下最常见的结果是验证通了但通的是另一个账号。 这种情况通常由 config 文件里IdentityFile指向错误导致。不要看到successfully authenticated就开心地跳过多花十秒钟确认用户名。5.5 忘掉 passphrase 只能重生成没有任何找回途径如果生成密钥时设置了 passphrase然后又把它忘了我建议直接放弃任何破解想法。唯一正确路径是删除旧私钥和旧公钥后台删除旧公钥重新生成一对新密钥再重新配置。整个过程大概五分钟远比花心思去找工具试图恢复口令更高效。5.6 Gitee 后台公钥修改是即时生效的不需要等待公钥在后台的增删基本秒级生效。如果修改之后仍然报Permission denied (publickey)问题几乎一定在本地私钥路径错了、ssh-agent 缓存了旧密钥、config 写错了对应关系。不要在后台反复删了加、加了删那样只是原地打转。我的个人习惯是所有长期维护的仓库尽量统一走 SSH 通道私钥文件放到加密备份里遇到只用 HTTPS 地址的协作场景就告诉自己公钥救不了 HTTPS私人令牌才是答案。每次被认证问题卡住先看通道再查凭据脑子里的排查链路清晰了报错也就不吓人了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
