GitHub SSH 密钥与算法新要求将如何影响开发者

GitHub 这轮 SSH 加固不会让所有开发者立刻更换密钥，真正需要优先处理的是仍依赖 RSA/SHA-1 签名、旧密钥交换算法或过旧 SSH 实现的开发机、CI 节点和集成工具。使用 HTTPS 远程地址的仓库不受影响；现有 RSA 密钥只要客户端能协商 rsa-sha2-256 或 rsa-sha2-512，通常也可以继续使用。

官方公告：https://github.blog/changelog/2026-09-22-security-improvements-for-ssh/

SSH 连接文档：https://docs.github.com/en/authentication/connecting-to-github-with-ssh

先确认影响范围和生效时间

这次变化针对通过 SSH 连接的 Git 客户端，以及 GitHub Enterprise Server 中未认证的 Git 协议场景。如果仓库远程地址以 https:// 开头，GitHub 明确说明这批 SSH 变化不会影响该连接。团队排查时应先按连接协议分流，而不是把所有仓库都纳入换钥计划。

时间上分为“新密钥约束”和“旧算法退场”两条线。2026 年 10 月 14 日，新上传的 RSA 密钥需要至少 3072 位；同日，GitHub.com 与部分 GitHub Enterprise Cloud with Data Residency 区域会启用 mlkem768x25519-sha256。随后两次 brownout 会短时模拟旧算法不可用，最终在 2027 年 1 月 13 日移除相关算法。GitHub Enterprise Server 方面，除后量子算法在 3.24 生效外，其余变化计划在 3.25 生效。

真正的风险在旧客户端和自动化节点

最容易误解的一点，是“RSA 密钥”与名称同为 ssh-rsa 的 RSA/SHA-1 签名类型并不是一回事。RSA 密钥本身可以使用 SHA-2 签名；只要客户端支持并正确协商 SHA-2，现有 RSA 密钥不必因为 SHA-1 被移除而重新生成。风险集中在不能稳定使用 RSA/SHA-2 的老客户端或老库。

GitHub 公告列出的稳健支持最低版本包括 OpenSSH 7.2p1、JSch 相关分支 0.1.66、TeamCity 2021.2.3、Go SSH 0.16.0、libssh2 1.11.0 和 PuTTY 0.82。个人电脑往往已经较新，真正容易遗漏的是长期不重建的 CI 镜像、旧版 IDE 插件、Java 构建服务器、嵌入式设备、机器人账号以及内部代理。

按资产清单完成兼容性排查

先找出仓库使用的协议，再记录真正发起 SSH 握手的软件与版本。不要只检查开发者笔记本，因为 CI Runner、构建容器和部署机器人可能使用完全不同的 OpenSSH 或 SSH 库。

# 查看仓库远程地址，先区分 SSH 与 HTTPS
git remote -v

# 查看当前 OpenSSH 客户端版本；CI 节点也要分别执行
ssh -V

# 展开对 github.com 生效的客户端配置，便于发现旧算法覆盖项
ssh -G git@github.com | grep -E '^(hostname|user|identityfile|hostkeyalgorithms|kexalgorithms) '

随后用详细握手信息确认实际协商结果。测试命令不会打开远程 shell；GitHub 文档说明成功认证后会返回用户名提示，而远程命令本身以状态码 1 退出。不要把这个退出码单独当成认证失败。

# 详细显示协商过程；不要把日志中的用户名或路径直接贴到公开工单
ssh -vvT git@github.com

# 查看已有公钥的类型与位数，只读取公钥文件，不暴露私钥
ssh-keygen -lf ~/.ssh/id_rsa.pub

如果日志显示客户端只能提出 ssh-rsa（RSA/SHA-1）签名，或只依赖即将移除的密钥交换机制，应优先升级客户端或上层 SSH 库。若工具把算法写死在配置里，即使系统 OpenSSH 很新，也仍可能受影响。

迁移时优先升级而不是批量换钥

对于已有 RSA 密钥，先升级客户端并确认能协商 RSA/SHA-2；这通常比批量撤销、重建和重新分发密钥风险更低。只有新上传 RSA 密钥时才需要满足至少 3072 位的要求。新建个人密钥时，GitHub 推荐在条件允许时使用 Ed25519；如果还要兼容只接受 RSA 的其他服务，再选择 3072 位以上的 RSA，实践中可直接使用 4096 位。

# 新建 Ed25519 密钥；用实际邮箱替换示例标签
ssh-keygen -t ed25519 -C "your_email@example.com"

# 旧系统必须使用 RSA 时生成 4096 位密钥，满足新的最低要求
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

企业团队还要把“密钥材料”和“客户端能力”拆开管理：密钥归属、撤销和轮换由身份流程控制；算法能力由基础镜像、构建代理、IDE 与依赖库版本控制。这样能避免为修复客户端协商问题而制造一次大规模密钥轮换。

把 brownout 当成生产演练

两次 brownout 的价值，是提前暴露只有在旧算法不可用时才出现的隐性依赖。团队可以在窗口前完成资产清单，在窗口期间观察克隆、拉取、推送、子模块、部署和机器人任务是否异常，并保留改用 HTTPS 或升级基础镜像的回退方案。不要临时在全局配置里重新开启弱算法，这只会把故障推迟到正式移除时。

常见问题

现有 2048 位 RSA 密钥会在 10 月 14 日失效吗？

GitHub 公告把至少 3072 位的要求限定为 2026 年 10 月 14 日之后新上传的 RSA SSH 密钥。现有密钥的关键检查项是客户端能否使用 RSA/SHA-2，而不是仅凭位数就判断立即失效。

启用后量子密钥交换需要手工配置吗？

通常不需要。支持并优先选择 mlkem768x25519-sha256 的客户端会自动协商；旧客户端应自动回退到其他受支持的密钥交换算法。真正需要处理的是只能使用即将移除算法的客户端。

团队应该先换密钥还是先升级客户端？

多数情况下先升级客户端。新密钥无法修复一个不会协商 RSA/SHA-2 或现代密钥交换算法的旧 SSH 实现；先完成客户端与依赖库盘点，再决定哪些密钥确实需要轮换。

怎样判断 IDE 或 CI 是否受影响？

确认它实际调用的是系统 OpenSSH、内置 SSH 还是某个库，并记录对应版本。用该工具真实执行一次 Git over SSH 连接，结合详细握手日志判断，而不是只看操作系统里的 ssh -V。