GitHub SSH 安全调整将至：从 ssh-rsa 到 ML-KEM 的兼容性排查与迁移

GitHub 在 2026 年 9 月 22 日发布 SSH 安全调整公告：后续会移除基于 SHA-1 的 ssh-rsa 签名和 diffie-hellman-group-exchange-sha256 密钥交换算法，新的 RSA 密钥还必须至少 3072 位，同时加入后量子密钥交换算法 mlkem768x25519-sha256。这不是“今天突然全部断连接”，但旧客户端、旧自动化脚本和多年没摸过的部署机，已经值得做一次兼容性盘点。

本文只处理 Git over SSH 的排查和迁移，不要求把现有 RSA 私钥全部推倒重来：能使用 RSA-SHA-2 的旧 RSA 密钥通常可以继续使用；新建密钥则优先选择 Ed25519。

GitHub SSH 安全调整迁移路径

一、先分清哪些连接会受影响

如果 Git remote 使用 https://，这次 SSH 算法调整不直接影响 Git 拉取和推送。只有通过 SSH 连接 GitHub 的 Git 客户端，以及 GitHub Enterprise Server 上使用未认证 Git 协议的场景，需要检查算法协商。

git remote -v
git config --get remote.origin.url
ssh -V

不要只看“仓库还能不能拉取”。自动部署、镜像同步、定时备份可能使用另一份 SSH 配置，真正要检查的是执行任务时使用的用户、私钥和 ssh_config。

二、用详细日志确认实际协商结果

先做只读探针，不修改密钥，也不把私钥内容打印到日志：

ssh -vvT git@github.com 2>&1 | \
grep -E 'kex: algorithm|host key algorithm|signature algorithm|Offering public key|Server accepts key'

输出中的 kex: 是密钥交换，signature algorithm 是签名算法。若看到客户端尝试 ssh-rsa 或 diffie-hellman-group-exchange-sha256，不要立即用永久配置强行兼容，先确认本机 OpenSSH 版本和目标端支持的算法。

ssh -Q key
ssh -Q kex
ssh -Q sig

不同发行版的 OpenSSH 编译选项可能不同，命令清单比“系统看起来很新”更可靠。

三、现有 RSA 密钥不一定要更换

GitHub 公告明确区分了密钥类型和签名算法：ssh-rsa 既可能被用来指 RSA 密钥类型，也可能指 RSA+SHA-1 签名类型。现有 RSA 密钥只要客户端能使用 rsa-sha2-256 或 rsa-sha2-512，通常不需要重新生成。

ssh -G github.com | grep -Ei 'pubkeyacceptedalgorithms|hostkeyalgorithms|kexalgorithms'
ssh-keygen -lf ~/.ssh/id_rsa.pub

第二条命令只输出公钥指纹和位数，不会泄露私钥。若 RSA 位数低于 3072，虽然公告中的新密钥门槛尚未等同于“现有密钥立即失效”，仍建议安排迁移窗口。

四、新密钥优先使用 Ed25519

对新设备或新部署用户，优先生成独立的 Ed25519 密钥，并通过 GitHub 账号页面添加对应公钥。下面的注释邮箱只是占位符：

ssh-keygen -t ed25519 \
  -f ~/.ssh/id_ed25519_github \
  -C 'deploy@example.invalid'
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_github
chmod 644 ~/.ssh/id_ed25519_github.pub

不要把私钥复制到 CI 日志、工单或仓库。部署机可以用 ssh-agent 管理私钥，也可以在独立的 ~/.ssh/config 中用 IdentityFile 指定路径，避免多账号之间串钥匙。

五、用 Host 配置隔离 GitHub 连接

多账号或迁移期间，建议为 GitHub 单独定义别名。这样改动只影响 GitHub，不会误伤其他 SSH 服务器：

Host github-deploy
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes
    AddKeysToAgent yes

然后把 remote 写成：

git remote set-url origin git@github-deploy:OWNER/REPOSITORY.git
ssh -T git@github-deploy

OWNER/REPOSITORY 是示例占位符。正式使用时保留仓库原有路径，不要因为改别名顺手改仓库名。

六、兼容旧系统时只做临时、按主机的验证

如果某台旧设备升级前必须验证 RSA-SHA-2，可以临时显式指定算法，验证完成后再决定是否写入配置：

ssh -o PubkeyAcceptedAlgorithms=rsa-sha2-512 \
    -o HostKeyAlgorithms=+ssh-rsa \
    -T git@github.com

这里的 HostKeyAlgorithms=+ssh-rsa 只是兼容性实验选项，不应当作为长期修复方案；它可能重新允许较弱的主机密钥算法。更不能把网上复制来的“全部算法加回去”配置放进全局 /etc/ssh/ssh_config。

七、按时间表安排迁移，而不是等 brownout

GitHub 公告列出的近期节点是：2026 年 10 月 14 日启用新的 RSA 密钥位数要求和后量子密钥交换；11 月 4 日、12 月 9 日分别对旧签名和旧密钥交换进行 brownout。brownout 的意义是制造可观测的失败窗口，不是给生产系统留一块永久兼容区。

公告页面末项日期显示为“2026 年 1 月 13 日”，与 9 月 22 日的发布时间和前面节点存在明显时间矛盾。本文不把它当作未来截止日，最终移除日期应以 GitHub 后续修订公告为准；这类日期冲突本身就是提醒：安全变更要保存原始公告和复核时间，不能只抄一行倒计时。

八、验收清单：连接成功只是第一关

所有 Git remote 已分类：HTTPS、个人 SSH、部署 SSH、镜像任务分别列出。
旧设备记录了 OpenSSH 版本、实际用户、配置文件和协商日志摘要。
新 RSA 密钥至少 3072 位；新部署优先使用 Ed25519。
生产配置没有全局放宽弱算法，临时兼容参数已删除或限定到单个 Host。
用与定时任务相同的用户执行 git ls-remote origin，再做一次最小化的测试推送或只读流水线验证。
把 10 月 14 日前的迁移结果写进变更记录，并在 11 月 4 日、12 月 9 日 brownout 前复查。

最后再强调一次：这次调整的重点不是“RSA 密钥一律作废”，而是淘汰 SHA-1 签名、移除旧密钥交换，并提高新 RSA 密钥门槛。先看实际协商结果，再按主机、按账户、按任务迁移，通常比全网批量换钥匙更稳。