弥勒鹿每次在终端里敲 git push，然后被要求输入用户名和密码——准确说是输入用户名和 Personal Access Token，因为 GitHub 早就把账号密码方式给禁了——这种体验一次两次还能忍，天天来就非常烦。而 SSH key 就是解决这个问题的标准方案：配置好之后，push、pull、clone 全部免密，安全感还比口令强得多。我见过太多人在这一步卡住，要么是密钥算法选错、生成出来的 key 不兼容，要么是配好了 ssh-agent 却老是报错，或者把公钥粘到 GitHub 上之后依然 Permission denied。
这篇就围绕 GitHub SSH key 的完整配置链路来写：从算法选型、密钥生成、ssh-agent 管理，到注册进 GitHub 账户、最终验证连通性，把每一步的原理和实操都讲透，还会专门聊聊 Windows 上那个非常经典的 ssh-agent 服务错误 1058。无论你是第一次配置的新手，还是换了电脑重装系统后想重新配一遍的老手，都可以直接照着操作。
1. 为什么推荐用 SSH key 而不是 HTTPS 口令
1.1 HTTPS 方式的痛点
很多人的第一个 GitHub 仓库都是用 HTTPS 地址 clone 的，因为 GitHub 给的默认提示就是 HTTPS。这个方式本身能用，但日常体验确实不够顺。2021 年 8 月之后，GitHub 彻底不再接受账号密码作为 git 操作的认证方式，你必须使用 Personal Access Token 或者 SSH key。用 HTTPS 加 token 的操作模式是：clone 的时候要求输入用户名，密码位置粘贴 token。token 那一长串字符谁记得住？每次都得去翻笔记或者重新生成。
更要命的是 token 有有效期。GitHub 允许你自己设置过期时间，但无论设多久，到期之后你都得重新生成、再重新配置。如果你手上有三四台设备，每台设备都要维护一份 token，这个维护成本相当可观。有人可能会说“我用 credential manager 缓存了，不用每次输”，那只是把凭据存在本机，换一台新机器、换一个用户、或者清理了凭据管理器之后，一切照旧。
1.2 SSH key 的认证逻辑
SSH key 采用的是公钥加密、私钥签名的认证方式。有一个很直观的类比：公钥是一把锁，你可以把它复制无数份，随便放到服务器上、放到 GitHub 账户里；私钥是钥匙，只有你自己有，绝不出本机。当你执行 git push 的时候，远程服务器会拿着一串随机数据过来，你的 SSH 客户端用私钥对它签名，服务器用你留在账户里的公钥验证签名是否匹配。验证通过，连接建立，整个过程中私钥不会在网络上传输。
这个机制带来的好处很明显：私钥不需要记住、不需要输入、不会被钓鱼页面骗走（除非你主动泄露），公钥泄露的问题也不大，因为你可以在 GitHub 后台随时删除或更换。对于日常频繁操作 GitHub 的人来说，SSH key 相当于一次配置、长期免密，收益非常明确。
1.3 两种方式的核心差异
| 对比维度 | HTTPS + Token | SSH Key |
|---|---|---|
| 认证材料 | 用户名 + Personal Access Token | 公钥 + 私钥 |
| 是否需要记住凭据 | 需要，token 是一长串随机字符 | 不需要，私钥由 ssh-agent 管理 |
| 有效期 | token 可设置过期时间，会失效 | 理论上永久有效，可后台手动撤销 |
| 多设备维护 | 每台设备都要配置 token | 每台设备生成独立密钥对即可 |
| 日常操作 | 配置不当仍会频繁要求输入 | 配好之后完全静默 |
| 安全性风险 | token 有被截图、误粘贴的风险 | 私钥泄露风险主要来自本机安全 |
如果你只是偶尔 clone 一个公开仓库，用 HTTPS 倒没什么问题。但只要是正经做开发、每天要多次 push 的人，我建议一次性把 SSH key 配好，这个投入非常值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 密钥算法选型：ed25519 为何是当前首选
2.1 GitHub 支持哪些算法
GitHub 的 SSH 服务端目前支持的公开密钥算法包括 ecdsa-sha2-nistp256、ssh-ed25519、ssh-rsa（需要 RSA 密钥长度不低于 2048 位）。老的 DSA 算法早在 GitHub 这边就已经被移除了，所以完全不用考虑。
很多老教程还在让你用 ssh-keygen -t rsa -b 4096，这套流程放在五六年前没问题，放在今天就不是最优解了。官方文档里推荐的生成命令是 `ssh-keygen -t