Git clone 报 Permission denied (publickey) 是 SSH 认证失败，非 Git 本身问题；需用 ssh -T 测试连接、检查 SSH agent、key 路径及 ~/.ssh/config 配置，并注意 Windows 多终端代理差异。
Git clone 报 Permission denied (publickey) 怎么快速定位
这不是 Git 本身的问题，而是 SSH 认证失败。Git 只是把 SSH 的拒绝原样抛出来，所以得先确认 SSH 连的到底是哪个 host、用的哪个 key。
实操建议：
- 运行
ssh -T git@github.com（或你实际用的域名，比如git@gitlab.example.com）——看报错里具体是哪个用户、哪个 host 被拒 - 检查当前 shell 是否用了代理或非默认 SSH 配置：
echo $SSH_AUTH_SOCK和ssh-add -l看有没有加载 key - 确认
~/.ssh/config里有没有写错Host别名或IdentityFile路径，比如把IdentityFile ~/.ssh/id_rsa_gitlab写成~/.ssh/id_rsa_gitlab.pub（后缀写错就白配） - Windows 用户特别注意：Git Bash 和 Windows Terminal 可能用不同 SSH agent，
ssh-add -l在一个终端有结果，换一个可能为空
git push 失败提示 remote: Permission to xxx/yyy.git denied to user(zzz)
说明认证通过了（SSH 或 HTTPS 登录成功），但你的账号没仓库写权限。常见于团队协作或 fork 后误推主仓。
实操建议：
- 先查当前 remote 地址：
git remote get-url origin，确认是不是推到了自己 fork 的地址，还是误设成上游仓库 - 如果是 GitHub/GitLab，打开浏览器访问该仓库主页，右上角点 “Settings” → “Collaborators and teams”（GitHub）或 “Members”（GitLab），确认你账号是否被授予
write或maintainer权限 - HTTPS 方式下，凭据可能缓存了旧账号：
git config --get credential.helper，然后用系统凭据管理器（macOS Keychain / Windows Credential Manager）删掉对应 host 的记录 - 别依赖
git config --global user.name—— 它只影响 commit author，和服务器权限完全无关
本地文件权限混乱导致 git status 显示大量 modified（但内容没变）
本质是 Git 检测到文件可执行位（chmod）或行尾符（CRLF/LF）变化，尤其在跨平台（Windows ↔ macOS/Linux）或切换 Git 安装方式（Git for Windows vs WSL）时高频出现。
实操建议：
- 先看是哪类变更：
git status --ignored+git diff --stat，如果全是100755 → 100644就是可执行位问题 - 统一关闭自动处理可执行位（除非项目真需要）：
git config core.filemode false（仅对当前仓库加--local，全局慎用） - 行尾符问题优先交由 Git 管理：
git config core.autocrlf true（Windows）或input（macOS/Linux），改完后重置工作区：git rm --cached -r . && git reset --hard - 别手动
chmod -R 755 .整个 repo —— Git 不跟踪目录权限，且会污染暂存区
CI/CD 流水线里 git clone 失败，错误含 fatal: could not read Username for 'https://xxx'
HTTPS 协议下，Git 在无交互环境里不会弹出用户名密码框，而 CI 默认不提供凭据，必须显式注入 token 或配置 SSH。
实操建议：
- 优先用 Personal Access Token（PAT）替代密码：
https://<code>token@github.com/owner/repo.git，注意 token 必须有reposcope（GitHub）或read_repository（GitLab） - GitHub Actions 可直接用内置
${{ secrets.GITHUB_TOKEN }}，但注意它默认只对本仓库有效，跨仓库需另配 - GitLab CI 推荐用
CI_JOB_TOKEN：https://gitlab.example.com/api/v4/projects/<code>PROJECT_ID/repository/archive.zip?job_token=${CI_JOB_TOKEN} - 避免在 URL 里硬编码 token —— 会被流水线日志明文打印，务必用 secret 注入并禁用日志输出（如 GitHub 的
mask功能）
权限问题最麻烦的不是报错本身，而是它常在多层抽象间跳转：SSH 配置、Git 凭据、服务端 RBAC、CI 环境变量、甚至文件系统 umask。每次卡住，先明确「是网络层？认证层？授权层？还是 Git 自己的元数据层」，再往下挖。
