GitHub添加SSH Key后仍提示“Permission denied”如何解决？

Question

GitHub添加SSH Key后仍提示“Permission denied (publickey)”是高频问题，常见原因包括：① SSH密钥未正确加载到ssh-agent（需执行 `eval "$(ssh-agent -s)"` + `ssh-add ~/.ssh/id_rsa`）；② GitHub账户绑定的是错误公钥（检查 `cat ~/.ssh/id_rsa.pub` 与 GitHub Settings → SSH and GPG keys 中添加的是否一致）；③ Git远程URL仍为HTTPS格式（应改为 `[e-mail]:username/repo.git`，可用 `git remote set-url origin [e-mail]:username/repo.git` 修正）；④ SSH配置文件（`~/.ssh/config`）中Host别名或IdentityFile路径有误；⑤ 权限设置不当（私钥文件权限必须为600：`chmod 600 ~/.ssh/id_rsa`）。可运行 `ssh -T -v [e-mail]` 查看详细连接日志，精准定位失败环节。建议按“验证密钥→启动agent→确认URL→检查权限→调试连接”五步排查。

Answer 1

```html

一、现象层：精准复现与基础验证

当执行 git pull 或 ssh -T [e-mail] 时，终端持续输出 Permission denied (publickey)，但 ls -la ~/.ssh/ 显示密钥文件存在——这表明问题不在“有无”，而在“可用性”与“匹配性”。该错误是 SSH 协议在认证阶段被服务端主动拒绝的明确信号，非网络连通性问题，亦非 GitHub 服务宕机（可通过 GitHub Status 实时验证）。

二、机制层：SSH 认证链路的五段式信任模型

GitHub 的 SSH 认证并非单点操作，而是依赖严格串联的五个信任环节：

1. 密钥存在性：私钥（id_rsa）与公钥（id_rsa.pub）成对生成且未损坏；
2. 代理加载性：ssh-agent 进程存活并已通过 ssh-add 注册对应私钥；
3. 路由匹配性：Git 使用的远程 URL 必须为 SSH 格式（[e-mail]:owner/repo.git），且 ~/.ssh/config 中若定义了 Host github.com 别名，其 IdentityFile 必须指向有效路径；
4. 权限合规性：私钥文件权限必须为 600（chmod 600 ~/.ssh/id_rsa），目录 ~/.ssh 权限不得高于 700；
5. 服务端一致性：GitHub Settings → SSH and GPG keys 页面中粘贴的公钥内容，必须与本地 cat ~/.ssh/id_rsa.pub 输出逐字符完全一致（含末尾换行、空格、注释）。

三、诊断层：结构化排查流程（五步黄金法则）

graph TD
  A[验证密钥] --> B[启动并加载 ssh-agent]
  B --> C[确认 Git 远程 URL 为 SSH 格式]
  C --> D[检查 ~/.ssh 权限与 config 配置]
  D --> E[执行 ssh -T -v [e-mail] 捕获详细日志]
  E --> F[定位日志中首个 FAIL 节点]

四、实操层：关键命令与典型输出对照表

操作目标	推荐命令	预期成功输出特征
检查公钥一致性	cat ~/.ssh/id_rsa.pub | pbcopy（macOS）或 cat ~/.ssh/id_rsa.pub | clip（Windows WSL）	复制后与 GitHub 界面中 key fingerprint 后 8 位比对是否一致
重载 ssh-agent 并添加密钥	eval "$(ssh-agent -s)" && ssh-add -l && ssh-add ~/.ssh/id_rsa	ssh-add -l 应返回类似 2048 SHA256:xxx ... (RSA)
强制切换远程 URL	git remote set-url origin [e-mail]:username/repo.git	执行后 git remote -v 显示两行均以 [e-mail]: 开头
验证 SSH 连接全流程	ssh -T -vvv [e-mail] 2>&1 | grep -E "(debug|Authentication|Offering|Accepted)"	日志中应出现 Authentication succeeded 及 Hi username! You've successfully authenticated...

五、进阶层：高级陷阱与企业级规避策略

对于资深开发者，还需警惕以下隐性风险：

• 多密钥共存冲突：若 ~/.ssh/config 中未显式指定 IdentitiesOnly yes，OpenSSH 可能尝试所有可用密钥，导致 GitHub 在第 5 次失败后直接断连（RFC 4252 §7）；
• ED25519 密钥兼容性：GitHub 自 2021 年起默认推荐 ssh-keygen -t ed25519 -C "[e-mail]"，但旧版 CentOS 7 / RHEL 7 默认 OpenSSH 版本低于 6.5，不支持该算法；
• WSL2 与 Windows 主机密钥隔离：在 WSL2 中生成的密钥无法被 Windows 原生 Git for Windows 读取，反之亦然，需统一环境或启用 OpenSSH Server 代理转发；
• CI/CD 流水线密钥注入：GitHub Actions 中使用 ssh-agent 需配合 webfactory/ssh-agent action，并确保私钥以 secrets.SSH_PRIVATE_KEY 形式 Base64 解码注入；

六、根因层：从协议规范看失败本质

根据 RFC 4252 §5.2，当 SSH 服务端判定客户端提供的公钥签名无效、密钥未注册、或签名算法不被接受时，将发送 SSH_MSG_USERAUTH_FAILURE 消息并携带 publickey 方法名。GitHub 的实现在此基础上叠加了速率限制与指纹绑定逻辑——这意味着即使密钥本身有效，若其指纹未在用户账户中预登记，仍会返回相同错误码，造成“黑盒式失败”表象。

七、防御层：自动化检测脚本（Shell）

#!/bin/bash
echo "=== GitHub SSH 连通性自检报告 ==="
echo "1. 密钥存在性: $(ls -la ~/.ssh/id_rsa* 2>/dev/null | wc -l) files"
echo "2. ssh-agent 状态: $(pgrep -u $USER ssh-agent | wc -l)"
echo "3. 已加载密钥: $(ssh-add -l 2>/dev/null | wc -l)"
echo "4. Git 远程 URL: $(git remote get-url origin 2>/dev/null | head -c 30)..."
echo "5. 目录权限: $(stat -c "%A %U" ~/.ssh)"
echo "6. 公钥指纹: $(ssh-keygen -lf ~/.ssh/id_rsa.pub 2>/dev/null | awk '{print $2}')"
echo "7. GitHub 连通性测试（仅摘要）:"
ssh -o ConnectTimeout=5 -T [e-mail] 2>&1 | grep -E "(Hi|You've successfully|Permission denied)"

```