光启元前两天有朋友发消息问我，说自己明明 GitHub 账号密码都能登录网页，但 git push 到仓库的时候始终报 Permission denied (publickey)，网上搜了半天也没看明白，发过来的截图里一半是英文报错，一半是各种看不懂的 ssh-keygen 参数。这个场景我太熟悉了，GitHub 的 SSH 配置不复杂，但它卡人的地方不在“配置”本身，而在很多人没搞懂 SSH 到底在验证什么——你以为是密码不对，其实是本地根本没有能证明“你是你”的钥匙。
这篇文章我把 GitHub SSH 配置从原理到实操重新梳理一遍。不管你是刚接触 GitHub 的新手，还是已经在用 HTTPS 但受不了每次输凭证的老用户，又或者想在一台电脑上同时管理 GitHub、GitLab、服务器多套密钥，按下面的顺序操作一遍基本都能跑通。文末我还会把这些年真正踩过的几个坑单独列出来，那些才是官方文档和大多数教程不会跟你讲明白的细节。
1. 先搞懂一件事：SSH 认证和“密码”没有任何关系
1.1 HTTPS 和 SSH 两种连接方式的本质区别
GitHub 给用户提供了两种远程仓库的交互协议：HTTPS 和 SSH。很多人默认用 HTTPS，因为 clone 的时候复制链接最方便，但从来没细想过两者背后的认证机制完全不一样。
HTTPS 方式下，Git 会把请求发送到 GitHub 服务器，由服务器验证你的身份，验证通过后才有权限读写仓库。早期可以直接用账号密码，后来 GitHub 出于安全考虑，基本禁止了纯密码访问，必须用 Personal Access Token（个人访问令牌）替代。所以“HTTPS + 密码”这条路在今天几乎走不通，这就是为什么很多人在 HTTPS 推送时输入密码却反复失败的直接原因。
SSH 方式则不同。它的验证逻辑是“证明你持有一把钥匙”：你的电脑上保存了一把私钥，GitHub 账号里保存了对应的公钥。每次连接时，服务器用公钥生成一个只有对应私钥才能解开的挑战，客户端解开了，身份就验证通过。整个过程不涉及任何账号密码，也不需要每次都输入凭据。
这里有一个非常关键的认知转换：SSH 验证的是“这台电脑 + 这把私钥”，而不是“GitHub 账号 + 密码”。很多人在 A 电脑上配置好 SSH 后，换到 B 电脑又报 Permission denied，原因就是 B 电脑上没有那把能对上号的私钥。理解了这一点，后面所有排查思路都会变得清晰。
1.2 SSH 目录里每个文件是干什么用的
配置 SSH，本质上是往 ~/.ssh 目录里放几样东西。我们拿最常见的 Linux/macOS 环境举例，Windows 上路径一般在 C:\Users\你的用户名\.ssh，结构是一样的：
| 文件/目录 | 作用 | 保密程度 |
|---|---|---|
id_ed25519 |
私钥，你的身份凭证核心 | 绝密，绝不能外传 |
id_ed25519.pub |
公钥，可以放心提交给 GitHub | 公开 |
known_hosts |
记录已确认过指纹的主机，防止中间人攻击 | 不必保密 |
config |
配置不同主机使用哪把私钥，多账号场景的关键 | 可以公开 |
你可以把 ~/.ssh 想象成一个钥匙圈，公钥是钥匙的“锁芯图纸”，可以复印给别人；私钥是真正能开锁的铁钥匙，丢了就意味着任何拿到它的人都能冒充你访问仓库。GitHub 网站后台填的是那份“锁芯图纸”，本地要保住的是“铁钥匙”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从生成密钥到测试连通：一次跑通 GitHub SSH 配置
2.1 选算法与生成命令
现代 OpenSSH 客户端建议直接用 Ed25519 算法，生成的密钥短、安全性高、验证速度快，而且是 GitHub 官方明确支持的格式。打开终端执行下面这条命令：
bash复制ssh-keygen -t ed25519 -C "you@example.com" -f ~/.ssh/id_ed25519
解释一下每个参数的含义：-t 指定密钥算法类型，这里用的 ed25519；-C 是注释，通常填你的邮箱，它会被写进公钥文件的末尾，方便你在 GitHub 后台一眼看出这把钥