GitHub SSH Key 配置指南：ed25519算法、ssh-agent托管与高频故障排查-代码聚汇网

GitHub SSH Key 配置指南：ed25519算法、ssh-agent托管与高频故障排查

SSH keyed25519ssh-agent

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

我最近连续帮三四个同事处理过 GitHub SSH key 的问题，发现大家卡住的点其实高度一致：要么是生成密钥时用了老旧的 RSA 1024，要么是配了密钥但每次 push 都要输一遍口令，要么是 Windows 上 ssh-agent 服务压根没启动，报一个让人摸不着头脑的 error 1058。这篇文章就把完整流程从头到尾捋一遍，从生成算法选型、密钥对原理，到 ssh-agent 托管、注册到 GitHub 账户，再到高频故障排查，一次性说清楚。无论你是刚接触 GitHub 的新人，还是被 SSH 配置折磨过几次但没系统整理过的开发者，照着做基本能一次走通。

1. 为什么 GitHub 推荐使用特定 SSH 密钥算法

1.1 先理解公钥认证的基本逻辑

SSH key 不是一把简单的“密码”，而是一对文件：一个私钥，一个公钥。私钥留在你本地机器上，绝不上传、不泄露、不发给任何人；公钥则可以放心地放到服务器、代码平台，比如 GitHub。加解密时，服务端用你上传的公钥验证客户端的身份，客户端用私钥完成签名认证。整个过程不传输私钥本身，所以即使公钥被人拿走，也无法反向推出私钥。

要理解这个原理，可以类比成一把锁和钥匙的关系：公钥是锁，四处分发都没关系，别人拿到锁也开不了门；私钥是钥匙，只有你手上有，钥匙丢了就等同于开门权限暴露。GitHub 账户之所以推荐 SSH key，就是因为它比 HTTPS + 密码认证更安全，也省去了每次 push 都要输入用户名密码的麻烦。只要配置好一次，后续 git fetch、git pull、git push 都走密钥认证，全程无感。

1.2 算法选型：ed25519 对比 RSA

GitHub 官方文档明确列出了支持的 SSH key 算法，并且推荐的优先级是 ed25519 高于 RSA 4096。ed25519 是 EdDSA 签名算法的一种实现，基于 Curve25519 椭圆曲线，密钥长度短、签名速度快、安全性高。它的公钥只有 68 个字符左右，私钥也是精简的小文件，同时现代 OpenSSH 版本（6.5 以上，2014 年以后发布的版本）都原生支持。

RSA 虽然仍在支持列表里，但 GitHub 明确建议密钥长度至少为 3072 位，实际大家普遍用 4096 位。RSA 4096 本身并不算不安全，问题在于它更长、计算开销更大，在 SSH 握手阶段对比 ed25519 有明显性能差距。尤其是在频繁建立 SSH 连接的场景下，比如你同时操作多个仓库、多个远程主机，ed25519 的握手速度优势会体感非常明显。

有的开发者会问：那我一直用 RSA 也没出过问题，为什么要换？从实际操作体验上说，RSA 4096 只是慢一点，不至于不可用；但从工程实践和官方推荐看，新生成的密钥一律建议用 ed25519，旧密钥可以继续用，但没必要再生成新的 RSA 密钥对。简单总结就是：新项目新环境无脑选 ed25519，老密钥能跑就先不动，等下次重装系统或换机器再迁移。

对比项	ed25519	RSA 4096
密钥长度	固定 256 位椭圆曲线	4096 位
公钥字符数	较短（约 68 字符）	较长（约 740 字符）
签名速度	快	相对慢
GitHub 推荐度	首选	仍支持，但非首选
OpenSSH 最低版本	6.5+（2014 年之后）	所有现代版本
适用场景	新环境、日常开发	老系统兼容、特殊情况

1.3 确认你的 Git 和 SSH 版本支持

别急着敲命令，先确认本地环境。ed25519 算法需要 OpenSSH 6.5 以上版本支持，Windows 10 1809 以后自带的 OpenSSH 客户端版本都在 7.x 以上，macOS 自带的 ssh 也早就更新到支持 ed25519 的版本。Linux 发行版更不用担心，主流系统默认的 OpenSSH 版本都很新。

检查方法很简单，终端里执行：

bash复制ssh -V

看到输出中包含 OpenSSH_7.x、8.x、9.x 字样，就说明完全支持 ed25519。如果某个老系统输出的是 6.0 甚至更早的版本，那才需要考虑 RSA，但这种老环境在 2025 年的今天已经非常罕见了，不用过度担心。

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

2. 生成 SSH 密钥对的完整实操

2.1 检查是否已有密钥，避免覆盖

很多人拿到教程就直接执行 ssh-keygen，一路回车，结果把之前用的密钥覆盖了，等到别的服务器登录不上才反应过来。所以在生成之前，务必先看一眼 ~/.ssh 目录里有没有现成的密钥。

bash复制ls -la ~/.ssh

或

bash复制ls -la /c/Users/你的用户名/.ssh

如果你看到 id_ed25519、id_ed25519.pub 这样的文件，说明之前已经生成过 ed25519 密钥，直接用就行，不需要再生成。如果你看到 id_rsa、id_rsa.pub，说明你之前用的是 RSA 密钥，它可以继续用，也可以选择额外生成一把 ed25519 密钥用于 GitHub。这里有一个关键操作原则：生成新密钥时不要覆盖已有文件，而是取一个新文件名，比如 id_ed25519_github。

2.2 生成 ed25519 密钥的命令与参数说明

确认没有冲突之后，执行生成命令：

bash复制ssh-keygen -t ed25519 -C "你的邮箱@example.com"

参数含义拆解：

-t ed25519：指定密钥类型为 ed25519。这是 GitHub 推荐的算法。
-C "你的邮箱@example.com"：注释信息，通常会写你的 GitHub 注册邮箱，作用是方便你自己识别这把密钥属于哪个账户或哪台设备。它只是一个标识，不影响认证逻辑，但不是可选项，强烈建议写上，否则以后维护多把密钥时会分不清哪个是哪个。

执行后终端会提示：

code复制Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/你的用户名/.ssh/id_ed25519):

这里有几个选择：

直接回车，使用默认路径和文件名 id_ed25519。适合你只有一把 SSH 密钥的场景。
输入自定义路径，比如 ~/.ssh/id_ed25519_github。适合你有多把密钥、需要区分用途的场景，比如公司 GitLab 一把、个人 GitHub 一把。

我个人的习惯是：所有个人 GitHub 相关操作统一使用 id_ed25519_github，公司内网 GitLab 使用 id_ed25519_work，这样在 ~/.ssh 目录下一眼就能看清楚每把密钥的用途。这个习惯在设备多、账户多的时候非常省心。

2.3 passphrase 设置与 ssh-agent 的关系

接下来会提示：

code复制Enter passphrase (empty for no passphrase):
Enter same passphrase again:

这里很多人会纠结到底要不要设置 passphrase。设置 passphrase 相当于给私钥文件加了一层口令保护，即使有人偷走了你的私钥文件，没有 passphrase 也使用不了。不设置则更方便，ssh 连接时直接使用私钥文件，不用输入任何口令。

我的建议是：设置 passphrase，然后把私钥托管给 ssh-agent。这样既保住了安全，又不必每次连接都手动输入口令。具体逻辑在下一章展开，这里先记住结论：passphrase 不是麻烦，而是配合 ssh-agent 使用后可以做到“安全与便利兼得”。

还有一个小提示：passphrase 和 GitHub 账户密码没有任何关系，不要混为一谈。passphrase 只作用于你本地的私钥文件。

2.4 生成后的文件结构检查

生成完毕后，再执行一次 ls -la ~/.ssh，你应当看到两个新文件：

id_ed25519（或你自定义的文件名）：私钥，绝对不要泄露，不要提交到代码仓库。
id_ed25519.pub：公钥，可以放心上传到 GitHub 等平台。

公钥文件的内容是一行文本，以 ssh-ed25519 开头，后面跟一串 base64 编码的字符串，最后是你刚才写的注释。这个 .pub 文件就是我们下一步要复制并注册到 GitHub 账户里的东西。

注意：有些教程会让你用 clip < ~/.ssh/id_ed25519.pub 或 pbcopy < ~/.ssh/id_ed25519.pub 把公钥复制到剪贴板，这里要确认你复制的是 .pub 结尾的公钥，而不是不带 .pub 的私钥。把私钥内容粘贴到 GitHub 上，等于把自家门钥匙直接交给别人，这是一个极其危险的操作。

3. 使用 ssh-agent 托管私钥

3.1 为什么需要 ssh-agent

如果你给私钥设置了 passphrase，直接使用 ssh 连接时会要求你输入 passphrase。短时间连接一两次还好，但如果你每天要 push 十几次，每次都输一遍口令，很快就会烦。

ssh-agent 就是解决这个问题的：它是一个常驻后台的代理程序，你把私钥“添加”给 agent 后，第一次添加时输入一次 passphrase，之后 agent 就替你保管已解锁的私钥，后续 SSH 连接时 agent 自动完成身份认证，不再重复询问口令。可以理解成一个私钥专用的“钥匙串”，你只需要把钥匙放进钥匙串一次，之后每次开门它自动帮你拿钥匙。

这个机制在 macOS 上体验最好，因为 macOS 的 Keychain 可以把 passphrase 持久化到系统钥匙串里，重启电脑都不用重新添加；Windows 上的 OpenSSH Agent 服务也能做到，只是需要多配置几步；Linux 桌面环境下则取决于你是否配置了桌面环境的密钥环。

3.2 启动 ssh-agent 并注册私钥：三平台操作

不同系统的操作差异很大，分开说。

Linux / macOS：

先启动 agent：

bash复制eval "$(ssh-agent -s)"

这个命令会输出一个类似 Agent pid 12345 的结果，说明 agent 已经在后台运行了。

然后把私钥添加进去：

bash复制ssh-add ~/.ssh/id_ed25519_github

如果私钥设置了 passphrase，此时会要求你输入一次，之后就不再问了。

macOS 用户还可以用钥匙串持久化：

bash复制ssh-add --apple-use-keychain ~/.ssh/id_ed25519_github

这样重启系统后 key 依然在 agent 里，不用每次开机重新添加。早期版本用的是 -K 参数，新版 macOS 变成了 --apple-use-keychain，如果你用的是旧命令发现失效，换成新参数试试。

Windows：

Windows 的情况要特殊一些。Windows 10/11 自带 OpenSSH 客户端和 ssh-agent 服务，但这个服务默认是手动启动状态，有时候甚至是禁用状态。这也是很多人遇到 unable to start ssh-agent service, error :1058 的根源。

先检查服务状态。以管理员身份打开 PowerShell 或命令提示符：

powershell复制Get-Service ssh-agent

如果 Status 是 Stopped，StartType 是 Disabled，先改成手动启动：

powershell复制Set-Service -Name ssh-agent -StartupType Manual

然后再启动服务：

powershell复制Start-Service ssh-agent

再次执行 Get-Service ssh-agent，确认 Status 变成 Running。

服务跑起来之后，把私钥添加到 agent：

bash复制ssh-add $env:USERPROFILE\.ssh\id_ed25519_github

注意：Windows 上如果 ssh-agent 服务没有运行，直接执行 ssh-add 大概率会报 Could not open a connection to your authentication agent，这不是 ssh-add 的问题，而是 agent 服务没起来。先启动服务，再执行添加，顺序不能反。

3.3 error 1058 的深度排查

很多人遇到的 ssh-agent bash unable to start ssh-agent service, error :1058 就是在 Windows 服务没启用的情况下出现的。error 1058 对应的系统错误是“无法启动服务，原因可能是已被禁用或没有相关联的启用设备”，翻译成人话就是：服务是 Disabled 状态，系统拒接启动它。

解决思路前面已经给了，核心就是两行命令：

powershell复制Set-Service -Name ssh-agent -StartupType Manual
Start-Service ssh-agent

但这里还有两个细节值得注意。第一，PowerShell 必须以管理员权限运行，否则 Set-Service 会提示拒绝访问。第二，如果 StartType 设置成 Automatic（自动启动）会更省心，这样每次开机 agent 都自动运行，只是会常驻一个后台进程，占用资源极低，不影响使用。我个人推荐直接设成 Automatic，省得某天重启完忘记手动启动，git push 又莫名其妙要输口令。

3.4 用 ~/.ssh/config 管理多把密钥

如果你生成了多把密钥，比如公司一把、个人一把，SSH 默认会把 id_ed25519 当作认证密钥，这就可能导致你用公司密钥去请求 GitHub，或者反过来，GitHub 不认这把密钥，直接拒绝连接。

这时候需要在 ~/.ssh/ 目录下创建一个 config 文件（没有扩展名，就叫 config），用 Host 配置把不同的域名路由到不同的密钥文件：

code复制# 个人 GitHub 账户
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

解释一下每一行的作用：

Host github.com：别名，真正连接时使用的名称。
HostName github.com：实际连接的域名。
User git：SSH 连接 GitHub 时固定使用的用户名，GitHub 官方要求所有 SSH 连接的用户名都是 git。
IdentityFile ~/.ssh/id_ed25519_github：指定该连接使用哪把私钥。
IdentitiesOnly yes：告诉 SSH 只使用这里指定的密钥，不要尝试 agent 里所有的密钥。这个参数在多密钥场景下非常重要，不加它 SSH 会按顺序尝试所有可用密钥，如果第一个密钥不被 GitHub 接受，它可能直接跳过你指定的那把密钥，导致连接失败。

做完这步之后，执行 ssh-add -l 可以查看 agent 里已加载的密钥列表，确认你要用的密钥已经在里面了。

4. 将公钥注册到 GitHub 账户

4.1 复制公钥内容的方式

公钥注册前需要先把公钥内容复制到剪贴板。不同系统命令不一样：

Windows（PowerShell）：

powershell复制Get-Content $env:USERPROFILE\.ssh\id_ed25519_github.pub | Set-Clipboard

macOS：

bash复制pbcopy < ~/.ssh/id_ed25519_github.pub

Linux：

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

然后手动选中复制，或者用 xclip：

bash复制xclip -sel clip < ~/.ssh/id_ed25519_github.pub

复制完成后，内容是一行以 ssh-ed25519 开头的完整字符串，不要截断，不要加换行，整段粘贴到 GitHub 的输入框里。

4.2 在 GitHub 网页端添加 SSH key 的步骤

点击右上角头像，选择 Settings。
左侧菜单找到 SSH and GPG keys。
点击 New SSH key 按钮。
Title 字段填一个能识别来源的名字，比如 My Work Laptop 或 MacBook Pro 2025，建议写“设备名+用途”，方便以后吊销某台设备时一目了然。
Key type 选择 Authentication Key。GitHub 现在支持把同一把密钥同时用于认证和签名，但建议保持默认的认证用途即可，签名密钥单独生成。
Key 字段粘贴刚才复制的公钥内容。
点击 Add SSH key，根据提示输入 GitHub 密码或通过两步验证确认。

添加完成后，在 SSH and GPG keys 页面就能看到刚添加的密钥，并标注了添加时间和最后使用时间。

4.3 用 ssh -T 验证连通性

注册公钥后的第一件事就是测试连接是否正常。执行：

bash复制ssh -T git@github.com

第一次连接时，SSH 会提示确认 GitHub 服务器指纹：

code复制The authenticity of host 'github.com (IP地址)' can't be established.

这时输入 yes 并回车，确认指纹。之后如果看到类似这样的输出：

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

恭喜，说明 SSH 密钥已经生效，你的本地客户端和 GitHub 之间的认证链路已经完全打通。这句话的意思是认证成功，但 GitHub 不允许 shell 登录，这是预期行为，不是报错。

如果你看到 Permission denied (publickey)，那说明认证失败，需要回到前面的步骤逐步排查，下一章详细讲排查思路。

4.4 SSH key 与 HTTPS 认证的区别

配置好 SSH key 之后，要把你本地仓库的远程地址从 HTTPS 改成 SSH 才能真正免密推送。检查方式：

bash复制git remote -v

如果输出的是：

code复制origin  https://github.com/用户名/仓库名.git (fetch)
origin  https://github.com/用户名/仓库名.git (push)

说明当前用的是 HTTPS 方式，需要改成 SSH 地址：

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

改完之后再执行 git remote -v，地址应该变成 git@github.com:... 的格式。这一步经常被忽略，导致明明 SSH key 配置成功了，push 时仍然要输入账号密码。原因很简单——你连的地址还是 HTTPS，SSH key 压根没参与认证。

提醒：HTTPS 认证也有它的优势，比如 GitHub 现在不再支持密码 push，但支持 Personal Access Token（PAT），有些企业环境只开放 HTTPS 端口，那 SSH 可能连不上。选择哪种方式取决于你的网络环境，不要盲目迷信 SSH。

5. 日常使用高频问题排查

5.1 Permission denied (publickey) 的排查路径

这个报错出现频率最高。当你执行 ssh -T git@github.com 时如果看到：

code复制git@github.com: Permission denied (publickey).

按以下顺序逐个排查：

查看 agent 里有没有密钥：ssh-add -l，如果输出 The agent has no identities.，说明密钥没添加，执行 ssh-add ~/.ssh/id_ed25519_github。
确认 GitHub 上有没有该公钥：登录 GitHub 的 SSH and GPG keys 页面，把本地公钥内容对比一遍，确保一字不差。
确认 SSH 使用的是不是你指定的密钥：加上 -v 参数调试：ssh -T git@github.com -v，在输出中查找 Offering public key 和 Server accepts key 这两行，前者显示本地尝试了哪把密钥，后者显示服务端是否接受。
确认大写的 User 是 git：有些教程会让你写自己的用户名，其实 GitHub 规定 SSH 连接的用户名必须是 git，写成别的一定失败。

其中第 3 步的调试输出信息量最大，能直接看到 SSH 客户端尝试了哪把密钥、服务端拒绝了哪把密钥，比盲目重试高效得多。

5.2 密钥文件权限引发的怪问题

如果你在 Linux 或 macOS 上使用 SSH，私钥文件权限过宽会导致 SSH 直接拒绝使用这把密钥。错误信息可能是：

code复制Permissions 0644 for '/home/user/.ssh/id_ed25519_github' are too open.

SSH 出于安全考虑，要求私钥文件只能被当前用户读写，不能对其他用户开放任何权限。修复方式：

bash复制chmod 600 ~/.ssh/id_ed25519_github
chmod 700 ~/.ssh

Windows 上一般不会提示权限问题，但如果你在使用 WSL，同样要遵守这套权限规则。这个小细节坑过很多人，尤其是从 Windows 拷贝到 WSL 的密钥文件，默认权限往往就是 0644，直接用就会报错。

5.3 私钥和公钥别搞混

这个问题在 Gerrit、GitLab 等平台同样适用。有个高频疑问是“用密钥还是公钥”，答案非常明确：本地留私钥，平台注册公钥。私钥相当于身份凭证，公钥相当于识别标识。任何平台要求你上传的都是 .pub 结尾的公钥内容，任何要求你提供私钥内容的操作都要立刻警惕。

真实场景里还有人在 GitHub 上添加 key 时把私钥粘贴进去，GitHub 保存时不会拒绝，但认证会一直失败。因为服务端拿着你的公钥去验客户端签名，你贴上去的是私钥，匹配逻辑直接错乱。遇到这种问题，删掉重新添加正确的公钥即可。

5.4 SSH key 与 Personal Access Token 怎么选

前几年 GitHub 取消 HTTPS 密码认证后，不少人发现 HTTPS push 需要输入一个 token，但不知道这是什么。Personal Access Token（PAT）本质上是一个带权限范围的字符串令牌，走 HTTPS 认证；SSH key 走的是公钥加密认证。两者可以共存，没有冲突。

我个人建议：本机开发环境优先配置 SSH key，因为配置一次之后无感使用，且密钥安全性更高；临时在公共电脑或 CI 环境里需要推送时，用 PAT 更合适，用完即弃，不用在这台机器上留下私钥文件。GitHub 的 PAT 可以设置有效期和权限范围，尽量给最小权限，不要一把 token 开了 repo 和 workflow 的全量权限。

5.5 多台设备共用一个 GitHub 账号

如果你的台式机、笔记本都要访问 GitHub，不需要为每台设备注册同一个公钥，更推荐每台设备生成独立的密钥对，并分别注册到同一个 GitHub 账户下。这样做的最大好处是：某台设备丢失或淘汰时，只需要在 GitHub 后台删除那一台对应的公钥，不影响其他设备。

设备管理的命名建议：在 GitHub 的 Title 字段写类似 Desktop-2025、MacBook-Pro、WSL-Ubuntu 这样的名字，一目了然。公钥本身不携带设备信息，只有 Title 能帮你区分，命名千万别偷懒。

不过这里要注意，代理 NAT 环境下同一台电脑从不同网络连接，GitHub 看到的 IP 会变，但认证只认密钥，不受 IP 变化影响，所以不用担心换网络环境后密钥失效。

6. 从踩坑经历中沉淀的操作清单

6.1 一个从零到通的最短完整流程

如果你现在面对一台干净的开发机，参考下面这个最短路径操作，整个过程应该不超过五分钟：

bash复制# 1. 生成密钥，一路按需设置 passphrase
ssh-keygen -t ed25519 -C "your_email@example.com"

# 2. 启动 ssh-agent
eval "$(ssh-agent -s)"

# 3. 添加私钥到 agent
ssh-add ~/.ssh/id_ed25519

# 4. 输出公钥内容并复制
cat ~/.ssh/id_ed25519.pub

然后打开浏览器，把公钥粘贴到 GitHub 的 SSH keys 页面，保存。最后验证：

bash复制ssh -T git@github.com

看到 successfully authenticated 就说明全部配置完成。如果你的 Git 仓库远程地址还是 HTTPS，用前面提到的方法把 remote URL 改成 SSH 格式，然后就可以无感推送了。

6.2 服务重启后 agent 丢失密钥的应对

有一个问题很隐蔽：ssh-agent 只是把私钥解密的会话保存在内存里，它不会把私钥本身持久化。也就是说，重启电脑后 agent 里之前添加的密钥会清空，你执行 git push 时可能突然发现又要输入 passphrase。

macOS 上我已经通过 --apple-use-keychain 参数解决了。Windows 上如果你想重启后免输入，需要手动把私钥注册到 Windows 凭据管理器，或者每次开机后重新执行一次 ssh-add。目前 Windows 的 OpenSSH Agent 没有一个非常优雅的图形化配置界面，最简单的办法是把 ssh-add 写进 PowerShell 的启动脚本里，或者直接用 Git Bash 里自带的机制。

Linux 桌面环境下情况更复杂一些，取决于你用的是 gnome-keyring 还是 KWallet。如果你在 Linux 上追求无感体验，可以搜索一下 ssh-agent systemd user 或者你的桌面环境对应的密钥环方案，但这不是必须的，无非是每次开机多执行一条命令的区别。

6.3 密钥泄露后的紧急处理

如果怀疑私钥泄露，比如设备丢失、私钥文件被误上传到公共仓库，不要想着修改或补丁，正确做法是：立即登录 GitHub，在 SSH and GPG keys 页面把对应的公钥删掉，然后重新生成一对新密钥，把新公钥注册上去，同时更新本地和所有使用旧密钥的设备的配置。

这里特别提醒一句：很多人把 ~/.ssh 目录整个塞进了 Git 仓库，这是绝对禁止的操作。私钥一旦进了任何远端仓库，即使后来删掉，Git 历史里仍然能找到，必须当作泄露处理。正确做法是在 Git 仓库的 .gitignore 中加入 ~/.ssh/ 相关路径，并确保它永远不会被提交。

6.4 GitHub 连接不稳定时的排查思路

如果你发现 GitHub 有时候能访问，有时候连接超时，先不要急着怀疑 SSH key 配置有问题。SSH 认证成功与否和网络连通性是两回事。执行 ssh -T git@github.com -v 看卡在哪一步：如果卡在建立 TCP 连接阶段，多半是网络层面的问题，与密钥无关；如果 TCP 连接已经建立、卡在认证阶段，才需要考虑密钥配置。

网络层面的排查思路包括：尝试切换网络环境（比如从公司网络切到手机热点）、检查本地 DNS 设置、留意系统代理是否对 git 命令生效。这里尤其要注意的是，系统代理只对 HTTP/HTTPS 流量生效，对 SSH 的 22 端口不生效，如果你是通过代理访问 GitHub，SSH 连接很可能会超时。GitHub 官方支持 SSH over 443 端口，即 ssh.github.com:443，可以在 config 文件里配置：

code复制Host github.com
  HostName ssh.github.com
  Port 443
  User git
  IdentityFile ~/.ssh/id_ed25519_github

这个配置在部分禁用 22 端口的网络环境里是有效的，但我建议不要一开始就加上，只有当你确认 22 端口走不通时再启用。

6.5 养成检查 SSH 连接状态的习惯

最后分享一个我自己的习惯。每次在一台新设备上配置完 SSH key，我不会急着去 clone 仓库，而是先执行几组最基础的验证命令，确认链路完全正常再往下走：

bash复制ssh-add -l

确认 agent 里已经有预期密钥。

bash复制ssh -T git@github.com

确认认证通过。

bash复制git remote -v

确认仓库远程地址是 SSH 格式。

这三条命令总共花不了十秒钟，但能避免一个很尴尬的场景：你辛辛苦苦写了一下午代码，最后 push 的时候才发现认证有问题，然后一头扎进排障流程，把早已忘掉的 SSH 知识从头捡起来。养成这个习惯之后，我几乎没有再被 SSH 认证问题卡住过。

回到最开始的话题，GitHub 推荐 ssh key 软件密钥算法这件事，本质上不是让你背参数、记命令，而是让你理解公钥认证的工作机制。理解了私钥公钥的分工、agent 存在的意义、config 的作用，剩下的一切都是水到渠成的事。希望这篇文章能帮你把 SSH key 这关彻底打通，以后换设备、配新环境都能一次搞定。