Git SSH报错Permission denied (publickey)排查与修复完整指南-代码聚汇网

Git SSH报错Permission denied (publickey)排查与修复完整指南

程序员良许·2026-09-04·阅读 80 GEO检测（免费）

GitSSHPermission denied publickey

|难度：普通|阅读约 40 分钟

如果你是在新电脑上第一次执行 git clone git@github.com:xxx/project.git，迎面撞上 Permission denied (publickey)，大概率会跟我当年一样陷入两个误区：要么怀疑 GitHub 的 SSH 服务挂了，要么准备卸载重装 Git。这两个方向其实都跑偏了。

这条报错看起来吓人，但翻译成人话就是一句话：GitHub 没有认出你手里这把钥匙。它既不代表你的网断了，也不代表你的 Git 坏了，更不需要你把环境推倒重来。这篇文章就是围绕这个经典报错，从底层原理、完整排查链路、标准修复步骤到多密钥场景逐一拆开讲清楚，适合那些刚接触 Git、或者被这个问题卡过很多次但一直没搞懂原理的人。看完之后，遇到 Permission denied (publickey) 你不仅能自己解决，还能顺手帮同事解决。

1. 这条报错到底在说什么：先看懂 Git 的 SSH 认证模型

1.1 一条报错出现在哪五个典型现场

Permission denied (publickey) 最常见的出场时机就那么几个：git clone 一个仓库、git push 推送代码、git pull 拉取更新，以及手动执行 ssh -T git@github.com 测试连接。

这些操作表面看起来互不相干，但底层全走的是同一条 SSH 通道。任何一个环节断掉，Git 都只会丢给你这一句冷冰冰的提示。所以处理问题的第一步不是去网上复制命令，而是先搞清楚这句话背后的认证机制。

GitHub 的 SSH 认证模型非常直观：你的电脑上保存着一份私钥，GitHub 服务器上保存着你上传过的公钥。连接时，客户端向服务器证明"我有那把私钥"，服务器用公钥验证这个证明是否有效。验证通过，就放行；验证失败，就返回 Permission denied (publickey)。

你可以把它想象成小区门禁。公钥是物业登记的住户信息，私钥是你手里的门禁卡。保安（GitHub 服务器）不会看你的长相，只看你刷的卡能不能在系统里查到。卡不对、卡没登记、或者你压根没带卡，结果都是"拒绝进入"。

1.2 GitHub 的 SSH 认证为什么只谈 publickey

很多从 SVN 或其他代码托管平台转过来的同事会有一个习惯性疑问：我明明有 GitHub 密码，为什么不让我输密码？

这里要明确一个背景：GitHub 在 2021 年 8 月之后已经彻底移除了命令行密码认证方式。你在网页上用密码登录没问题，但在命令行里通过 HTTPS 协议操作仓库时，密码不再作为有效凭证，必须使用 Personal Access Token。而走 SSH 协议时，GitHub 压根不提供密码输入环节，唯一认可的凭证就是客户端提交的 publickey。

还要留意一下 SSH URL 的固定格式。git@github.com:用户名/仓库.git 里，git@ 这部分是固定的，git 是 GitHub SSH 服务的统一入口用户，不是你的 GitHub 账号。就算你把自己的 GitHub 用户名写在这个位置，GitHub 也只会当成固定入口处理。经常看到有人改成 张三@github.com:xxx/xxx.git，这种地址从一开始就是错的，报 publickey 反而是件很自然的事。

1.3 学会用报错的第一个单词快速分诊

这里我要分享一个很实用的经验：不要只看最后的括号，要看报错的第一个词。Permission denied (publickey) 虽然是最常见的，但它不是唯一的 SSH 报错。我把容易混淆的几种放在一起对比，你以后遇到类似问题可以先对号入座。

报错特征	问题层面	下一步该做什么
`Permission denied (publickey)`	SSH 认证层	密钥没配对、没登记或没被选中
`Host key verification failed`	主机信任层	known_hosts 里没有该主机的指纹，需要确认后加入
`Connection timed out` / `Connection refused`	网络层	根本没连到 GitHub 的服务器，不是密钥问题
`Repository not found`	仓库权限层	认证已通过，但账号没有该仓库权限或地址写错

这套分诊表对我来说价值很大。以前有个同事抱着 Permission denied 报错折腾了一个下午，各种生成密钥、重新添加公钥，最后发现他的问题是公司网络根本连不上外网，直接表现是连接超时——这是纯网络问题，重新生成一百次密钥也没用。反过来，如果报错是 publickey，那你也不需要去检查网络。

1.4 一个常见的误区：user.name 和 user.email 与 SSH 认证无关

还有一类人解决问题的姿势让我很无奈：一看到 SSH 连接失败，马上跑去改全局配置。

bash复制git config --global user.name "NewName"
git config --global user.email "new@example.com"

改完再试，当然还是报同样的错。原因很简单：user.name 和 user.email 只影响你提交代码时 commit 记录里显示的作者信息，跟 SSH 认证完全是两套体系。Git 提交代码时，把作者信息写进对象里，然后通过 SSH 通道把对象推给远程服务器；作者信息是"内容"，SSH 认证是"通道"——通道都不通，你改内容里的名字有什么用？

这个误区卡住了不少人，所以我专门把它放在前面说清楚。凡是遇到 publickey 问题，第一反应不要是去改用户名邮箱，而是进入下面这套排查链路。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 从 remote 到密钥的全链路排查：比重新生成密钥重要得多

遇到 publickey 报错，网上的标准答案可能就是"重新生成密钥再添加一遍"。但我建议你先别急，因为重新生成密钥是最后一个选择，而不是第一个选择。如果原来的私钥已经在别的平台登记过，贸然覆盖等于把多平台凭证一起弄失效，后续麻烦更大。

正确的姿势是沿着连接链路逐层排查，90% 的问题都能在这几步里找到答案。

2.1 先看克隆地址用的是 SSH 还是 HTTPS

排查第一步，确认你实际操作时使用的到底是哪种协议的远程地址。在项目目录里执行：

bash复制git remote -v

输出可能是两种形态：

text复制# SSH 协议
origin  git@github.com:用户名/仓库名.git (fetch)
origin  git@github.com:用户名/仓库名.git (push)

# HTTPS 协议
origin  https://github.com/用户名/仓库名.git (fetch)
origin  https://github.com/用户名/仓库名.git (push)

如果你看到的是 HTTPS 地址，理论上错误提示应该更偏向"密码认证已被移除"或"Personal Access Token required"，而不是 Permission denied (publickey)。但考虑到 Git 的凭证缓存机制比较复杂，有时候旧 token 失效后，Git 内部尝试多种认证方式，表现可能五花八门。为了不给自己埋雷，我建议你锁定这个事实：只要是在 GitHub 上操作 SSH URL 时出现的 publickey，就按本文的方法走；如果发现本来用的是 HTTPS，那问题可能出在 Token 上，不是 SSH key 上。

另外注意，GitHub 仓库页面上有 HTTPS 和 SSH 两个 Clone 地址按钮，很多人明明想用 SSH，却从默认的 HTTPS 标签页里复制了一长串链接，粘贴到终端就是 https 开头。复制时要确认选中了 SSH 标签。

2.2 检查本机 `~/.ssh` 目录里有没有可用的密钥对

确认远程地址走的是 SSH 之后，第二步就是看本地家目录下的 SSH 配置目录。

bash复制ls -al ~/.ssh/

正常情况下，你会看到下面这些文件里的若干个：

id_ed25519 和 id_ed25519.pub：Ed25519 算法的私钥与公钥
id_rsa 和 id_rsa.pub：RSA 算法的私钥与公钥
known_hosts：记录已确认过指纹的主机
config：SSH 客户端配置文件（不一定有）

如果这条命令提示目录不存在，或者目录下是空的，那基本可以下结论了：这台机器从来没生成过 SSH key。既然没有钥匙，GitHub 当然拒绝你。这就是大量新电脑用户报 publickey 的根本原因。

如果是目录存在但只有 known_hosts，同样说明没有生成过自己的密钥对。有些人会误以为 known_hosts 就是自己的公钥，其实完全不是，它只记录你连过的服务器指纹，相当于门禁系统里的"访客记录本"，而不是你的门禁卡。

2.3 核对 GitHub 账号里是否登记了这把公钥

本地有密钥文件之后，还要确认这个公钥是真的登记到了你的 GitHub 账号下。登录 GitHub 网页，进入：

text复制右上角头像 -> Settings -> SSH and GPG keys

在 SSH keys 区域看有没有条目。如果列表是空的，说明本地那对密钥虽然存在，但服务器端完全没有记录。这就像你手里有张门禁卡，但物业系统里没录入，刷卡当然没反应。

如果列表里有条目，则要把本地的公钥内容拿出来比对。查看公钥：

bash复制cat ~/.ssh/id_ed25519.pub

正常输出的结尾长这样：

text复制ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

把开头那段 ssh-ed25519 和一大串字符与 GitHub 密钥列表里显示的内容对比，看是否一致。很多时候用户在两台电脑上使用同一套公钥，但只把其中一口钥匙登记到 GitHub，另一台自然连不上。

2.4 用 `ssh -vT` 让 SSH 自己交代加载了哪些钥匙

如果上面的静态检查都没发现问题，但连接依然被拒，就该让 SSH 进入调试模式，自己交代问题出在哪了。执行：

bash复制ssh -vT git@github.com

-v 参数会让 SSH 打印完整的调试日志。别被一堆 debug 行吓到，重点看这几类关键信息：

text复制debug1: Will attempt key: /c/Users/你的用户名/.ssh/id_ed25519
debug1: Offering public key: /c/Users/你的用户名/.ssh/id_ed25519
debug1: Server accepts key: /c/Users/你的用户名/.ssh/id_ed25519
Authenticated to github.com ([IP地址]:22).

日志的解读逻辑就三条：

如果日志里连 Offering public key 都没出现，说明 SSH 客户端根本没找到可用的密钥文件，问题在本地。
如果出现了 Offering public key，但没有后续的 Server accepts key，说明这把密钥被 GitHub 拒绝了，问题在公钥未登记或绑定错了账号。
如果出现了 Authenticated to github.com，说明认证已经成功，报错可能来自 Git 层面的仓库权限或远程地址有误。

3. 标准解法：从生成密钥到验证成功的完整操作

如果你已经完成了全链路排查，确认了问题处在"没有密钥"或"公钥未登记"，那下面这套标准化流程就是解决它的正解。我在不同操作系统的机器上都跑过一遍，流程是完全一致的，只是复制公钥的小命令有点差异。

3.1 生成新密钥时选 Ed25519 还是 RSA

现在的 GitHub 官方推荐是 Ed25519。相比 RSA，它的密钥更短、生成速度更快、安全性也更高，而且 GitHub 早在 2021 年就完全支持了。除非你需要对接某些非常老旧的内部系统，否则没必要再用 -t rsa -b 4096 那一套。

生成命令：

bash复制ssh-keygen -t ed25519 -C "your_email@example.com"

这里有个小细节要解释：-C 后面的邮箱只是一个注释标签，作用是帮你记住这把密钥是干嘛用的。它不需要和你 GitHub 账号的注册邮箱一致，也不会影响认证结果。你甚至可以写一句 laptop-2025 这样的备注。

命令执行后，SSH 会询问保存位置：

text复制Enter file in which to save the key (/c/Users/你的用户名/.ssh/id_ed25519):

直接按回车使用默认路径即可，除非你有特殊理由改名。接着会提示设置 passphrase（口令）：

text复制Enter passphrase (empty for no passphrase):

passphrase 相当于给私钥再加一道锁，建议设置。虽然每次连接可能要输一次，比较繁琐，但可以通过 ssh-agent 缓存；如果不设置，私钥文件一旦泄露，别人就能直接使用。我的建议是设置一个你记得住的 passphrase，安全感和麻烦程度都能平衡。

3.2 公钥怎么安全地贴进 GitHub

密钥生成好后，本地会出现两个文件，一个没有后缀的是私钥，一个是 .pub 后缀的公钥。需要上传到 GitHub 的永远是公钥，私钥绝对不能发给任何人、绝不能上传到代码仓库或者粘贴到任何网页表单里。

查看公钥内容并复制，不同系统命令不同：

bash复制# Linux，使用 xclip 复制到剪贴板
xclip -sel clip < ~/.ssh/id_ed25519.pub

# macOS
pbcopy < ~/.ssh/id_ed25519.pub

# Windows Git Bash
cat ~/.ssh/id_ed25519.pub
# 然后手动选中终端输出内容复制
# 或者直接执行 clip < ~/.ssh/id_ed25519.pub

复制完成之后，回到 GitHub 的 Settings -> SSH and GPG keys 页面，点击 New SSH key。Title 栏随便填一个你能认出来的名字，比如 My Office PC、MacBook Pro 2025，方便以后清理不用的钥匙。Key 栏粘贴公钥，注意不要带入多余的空行或换行符，点击 Add SSH key 保存。

3.3 验证连接：一次成功时的输出长什么样

保存公钥后，回到终端执行验证命令：

bash复制ssh -T git@github.com

第一次连接时，SSH 会提示确认 GitHub 服务器指纹，显示类似 Are you sure you want to continue connecting (yes/no/[fingerprint])?，输入 yes 回车即可。

认证成功的标准输出是：

text复制Hi 你的GitHub用户名! You've successfully authenticated, but GitHub does not provide shell access.

看到这行就说明公钥登记成功，认证链路已经全通了。注意 Hi 后面的用户名到底是不是你当前想用的账号，这点在多账号场景下特别关键，后面我会专门展开。

3.4 把已有 HTTPS 远程仓库切换成 SSH 地址

有些项目一开始是用 HTTPS 方式克隆的，后来你想统一改用 SSH，不需要重新克隆一遍代码，只要改一下远程地址就行：

bash复制git remote set-url origin git@github.com:用户名/仓库名.git
git remote -v

修改后再执行 git push 或 git pull，Git 会走 SSH 通道。这一步本身不会解决 publickey，但它能保证你的后续操作都在同一套认证机制下，排查问题不会被 HTTPS 和 SSH 混合模式绕晕。

4. 密钥明明在但就是连不通：多密钥、多账号与配置文件

前两章解决的是"没有钥匙"和"钥匙没登记"的问题。但还有一类人，明明密钥文件在、GitHub 网页上也能看到对应公钥，却依然报 Permission denied (publickey)。这种诡异情况通常发生在多密钥、多账号场景。

4.1 GitHub 不认用户名，认的是 key 与账号的绑定关系

需要先明确一个关键事实：同一把公钥只能绑定一个 GitHub 账号。如果你在 A 账号下添加了某把公钥，然后尝试用这把公钥往 B 账号的仓库推送代码，GitHub 会返回 publickey 认证失败。

原因是 GitHub 的 SSH 认证逻辑里，公钥就是账号身份的凭证。服务器收到你的公钥后，去查这把公钥属于哪个账号，然后以那个账号的权限来执行操作。公钥同时属于两个账号会让服务器无法判断身份，所以干脆禁止这种设置。

在公司和个人两个 GitHub 账号共存的场景里，常见的问题就是：你把公司电脑上的公钥加到了个人账号，过几天又想用同一台电脑推公司仓库，结果发现怎么都推不上去。这个不是玄学，是公钥与账号的绑定关系不对。

4.2 默认只会自动使用几个固定名字的密钥文件

第二个高频坑是自定义文件名。OpenSSH 客户端默认会自动尝试的私钥文件是这些：

~/.ssh/id_rsa
~/.ssh/id_ecdsa
~/.ssh/id_ed25519

如果你生成的密钥文件叫 ~/.ssh/github_key 或 ~/.ssh/id_rsa_work，SSH 默认不会去碰它。有些人按照教程执行 ssh-keygen 时手滑改了文件名，生成完毕后在 GitHub 上也添加了，结果一样连不通，原因就在这里。

解决办法有三条路径：

重新生成密钥时使用默认文件名；
把已有密钥添加到 ssh-agent 里，让 SSH 能通过 agent 拿到它；
在 ~/.ssh/config 中显式指定该密钥文件。

用 ssh-agent 的方式：

bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa_work
ssh-add -l

ssh-add -l 可以列出 agent 当前加载的密钥列表。如果显示 The agent has no identities，说明没有密钥被加载到 agent。

4.3 用 `~/.ssh/config` 为不同密钥建立固定映射

如果只有一对密钥，其实配置完公钥就能直接通。但你如果有多台机器、多个账号、多对密钥，建议花两分钟把 ~/.ssh/config 写好，一劳永逸。

文件不存在就新建：

bash复制touch ~/.ssh/config

一个最基础的映射是这样的：

text复制Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

各字段的含义不多，但每个都很重要：

Host：你访问时的别名，SSH 会拿它去匹配对应配置块；
HostName：真实的主机名，通常保持 github.com；
User：固定写成 git，GitHub SSH 入口不接受其他值；
IdentityFile：指定使用哪把私钥；
IdentitiesOnly yes：强制 SSH 只使用上面指定的密钥，不要自作聪明地把 agent 里所有钥匙都递给服务器。

IdentitiesOnly yes 是我特别想强调的一个参数。默认情况下，如果 ssh-agent 里加载了多把密钥，SSH 会把它们一把一把地尝试提交给服务器。GitHub 的机制是只要它认可了其中一把，就按这把 key 对应的账号身份登录。如果 agent 里第一把 key 对应的是你的个人账号，而你当前想推的是公司仓库，GitHub 会直接以个人账号身份结束认证，根本不会继续尝试后面的公司 key。加了 IdentitiesOnly yes 后，SSH 只会提交配置里声明的这一把，从根源上避免了选错。

4.4 多账号时别怕用 Host 别名

基础 config 处理不了"同一台电脑要同时使用两个 GitHub 账号"的需求，因为两个账号都需要访问 github.com，但服务端只可能认出其中一把 key 对应的账号。

标准做法是把其中一个 Host 改成别名，让两个配置块在客户端层面互相独立：

text复制# 个人账号
Host github-me
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_me
  IdentitiesOnly yes

# 公司账号
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

配置之后，原地址 git@github.com:用户名/仓库.git 里的 github.com 不再直接使用，改由你定义的别名代替。克隆个人仓库时：

bash复制git clone git@github-me:你的个人用户名/仓库名.git

克隆公司仓库时：

bash复制git clone git@github-work:公司组织名/仓库名.git

对已有的远程仓库，用 set-url 改一下即可：

bash复制git remote set-url origin git@github-work:公司组织名/仓库名.git

这套方案我在多台电脑上实际跑过很多年，稳定可靠。核心思想是：别让 GitHub 去猜你要用哪个身份，而是在客户端就把身份锁死。

4.5 "ssh -T 显示的是另一个账号"怎么办

还有一种很让人头大的情况：认证确实成功了，但 ssh -T git@github.com 返回的 Hi 用户名不是你当前项目想用的账号。

这通常意味着：SSH 默认尝试的钥匙，或者 agent 里排在前面的钥匙，对应的是 A 账号，而 GitHub 愉快地认证成了 A。它不会发现后面还有一把属于 B 账号的钥匙，因为认证过程在 A 账号成功那一刻就结束了。

解决办法同样明确：不要用默认的 git@github.com 直连方式测试，而是写清楚别名，让 SSH 走 config 里对应的配置块：

bash复制ssh -T git@github-me

此时输出里如果正确显示了 B 账号的用户名，说明配置没问题。以后在项目里也统一用别名地址，就不会再出现身份串线的问题。

5. 环境与权限问题：耗时最长的暗坑清单

如果以上所有检查都做完了，密钥匹配、账号绑定都没问题，但问题依然存在，那就该看看环境层面了。这一章是各种稀奇古怪问题的汇总，每一条都是我在实际工作中踩过或帮别人排查过的真坑。

5.1 Linux/macOS 上私钥权限太宽

在 Linux 和 macOS 上，OpenSSH 对私钥文件的权限非常敏感。如果私钥的权限太宽（比如其他用户也能读），SSH 会直接拒绝使用它，报错类似：

text复制Permissions 0644 for '/home/你的用户名/.ssh/id_ed25519' are too open.

这种情况常见于从 U 盘、网盘或者压缩包里解压出来的 .ssh 目录。文件系统不会保留原来的权限设置，全部变成默认的 644，SSH 就不认了。

修复方法：

bash复制chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

私钥的权限应该严格限制为只有你自己可读可写，目录本身不能允许其他用户访问。公钥的权限可以宽松些，因为它是用来公开分发的。

5.2 Windows 上的两个 SSH 客户端与两种 HOME

Windows 环境是个重灾区，因为你的机器上可能同时存在两套 OpenSSH：

Git for Windows 自带的 OpenSSH，路径一般在 C:\Program Files\Git\usr\bin\ssh.exe
Windows 系统自带的 OpenSSH，路径一般在 C:\Windows\System32\OpenSSH\ssh.exe

这两套客户端读取的配置目录都遵循 %USERPROFILE%\.ssh 还是 $HOME/.ssh 的逻辑，但如果你设置了 HOME 环境变量，事情就变了。Git Bash 里执行：

bash复制echo "$HOME"

如果输出不是你预期的用户目录，而是某个奇怪的路径，那 SSH 就会去那个路径下找密钥。很多人把 HOME 指到了云盘同步目录或者网络驱动器，结果 ls ~/.ssh 能看到密钥，但 PowerShell 或 Git Bash 里连不上，因为两边读的不是同一个 HOME。

遇到这种情况，建议统一一下：要么所有终端都使用 Git Bash，并确保其中 HOME 指向 C:\Users\你的用户名；要么在使用系统 OpenSSH 时，在 Windows 环境变量里把 HOME 指向同一路径。

执行前还可以确认当前用的是哪个 ssh：

bash复制# Git Bash 中
which ssh

# PowerShell 中
Get-Command ssh

路径不同说明你实际调用的客户端不是你想象的那个，这点先对齐再继续排查。

5.3 机器迁移后直接复制 `.ssh` 目录的隐患

换电脑时，很多人图省事，直接把旧机器的 .ssh 整个目录拷贝到新机器。这个操作本身可行，但有三个隐患必须处理：

第一，权限重置问题。Windows 拷贝到 Linux，或者通过网盘同步到 macOS，目标目录的文件权限大概率是错的。需要按上一节的方法重新 chmod。

第二，known_hosts 冲突问题。旧机器的 known_hosts 里可能记录了旧的 GitHub 服务器指纹。如果 GitHub 那边做了密钥轮换，新机器去连时会报 Host key verification failed，而不是 publickey。真遇到时，可以把 known_hosts 里 github.com 那一行删掉，重新连接并确认指纹。

第三，公钥复制不等于公钥登记。把私钥复制到新电脑只是完成了本地一半，GitHub 上登记的仍是旧公钥的内容。好在你并不需要重新生成密钥，只要把 .pub 公钥内容重新复制到 GitHub 账户下即可。因为公钥本身就是同一个，GitHub 端不需要删除旧条目，允许同一个账号添加多份内容相同的公钥，只是不太建议这么干，留着旧条目也只能给旧机器用。

5.4 被忽略的 core.sshCommand 与 GIT_SSH 环境变量

还有一种隐蔽情况：项目或全局 Git 配置里被写入了自定义 SSH 命令。

bash复制git config --get core.sshCommand

如果输出非空，比如有人之前为了指定密钥执行过：

bash复制git config core.sshCommand "ssh -i ~/.ssh/id_rsa_old -F /dev/null"

那这个项目里的所有 Git SSH 操作都会强制走这条命令，指定使用 id_rsa_old，并且 -F /dev/null 会直接忽略 ~/.ssh/config。哪怕你后来在 config 里写了正确的映射，也不会生效。

环境变量里也可能存在类似干扰：

bash复制echo "$GIT_SSH_COMMAND"
echo "$GIT_SSH"

如果这些变量有值，Git 会优先使用它们。排查时把输出清空或修正，再重新操作一次。我建议在新环境里先确认这些配置为空，避免被旧机器的"遗毒"坑到。

5.5 网络连接超时不是 publickey 能解决的

最后说一个很容易被情绪带偏的情况。如果你执行：

bash复制ssh -T git@github.com

得到的不是 Permission denied (publickey)，而是 Connection timed out 或 Connection refused，那应当立刻停止在密钥层面折腾，因为你的请求根本没有到达 GitHub 的认证服务。

publickey 报错说明双方还能对话，只是不认钥匙；超时说明双方压根没通上话。这种问题通常是网络环境、路由器或防火墙策略导致的。遇到它时，建议先换一个确认正常的网络环境做对照测试。如果换个网络马上就能通，说明是本机所在网络的问题，需要联系网络管理员或换网络；如果任何网络下都超时，才需要检查本机防火墙、DNS 配置或者 SSH 客户端本身。

为什么专门提这点？因为我见过太多人在超时场景下反复重新生成密钥，纯属南辕北辙。网络层的问题，密钥再新鲜也解决不了。

回到最初那个问题。我现在遇到 Permission denied (publickey) 时，心里的第一反应已经不再是"坏了，Git 出问题了"，而是形成一个很自然的检查顺序：先用 git remote -v 确认协议，再 ls ~/.ssh/ 看密钥文件，接着登录 GitHub 页面核对公钥，最后用 ssh -vT 看日志定位。这一套流程走下来，绝大多数情况下五分钟内就能找到问题。

也顺便分享一个我自己的习惯：给密钥文件起有意义的名字，并把 ~/.ssh/config 维护好，每一对密钥对应哪个平台、哪台机器都写得清清楚楚。这样做的好处是，半年后再打开 .ssh 目录，你不会对着一堆 id_rsa、id_rsa_3 发呆。GitHub 的 SSH 问题说穿了不复杂，本质就是"钥匙、锁和配锁记录"三者是否对得上。把这篇的排查链路走一遍，下次再遇到它，你会觉得比改个 user.email 还简单。