GitHub 将调整 SSH 连接支持的算法：移除使用 SHA-1 的 RSA 签名和一种旧密钥交换算法，提高新上传 RSA 密钥的最低长度，并增加后量子密钥交换支持。SSH 是 Git 客户端连接 GitHub 的一种方式；如果你的 Git 远程地址以 https:// 开头，这些 SSH 调整不会影响该连接。

这次变化最容易引起误解的是 ssh-rsa：它既可能指 RSA 密钥类型，也可能指使用 SHA-1 的签名类型。GitHub 要移除的是后者，不是所有 RSA 密钥。多数用户无需立即重建现有密钥，但应确认所用 SSH 客户端或程序库能够使用 RSA-SHA2 签名。

具体会改哪些算法和密钥要求

SSH 建立连接时，会协商如何验证身份、如何交换会话密钥等参数。签名算法用于证明持有相应私钥的一方身份可信；密钥交换算法则用于双方协商本次连接使用的会话密钥。它们承担不同职责，因此移除某种签名类型，不等于移除某种密钥交换方式。

• 移除 SHA-1 RSA 签名：GitHub 将停止接受签名类型 ssh-rsa，即使用 SHA-1 的 RSA 签名；使用 SHA-1 签名的 ssh-rsa-cert-v01@openssh.com 证书也包括在内。RSA 密钥仍可使用 rsa-sha2-256 或 rsa-sha2-512，分别以 SHA-256 或 SHA-512 生成签名。
• 移除一种旧密钥交换算法：diffie-hellman-group-exchange-sha256 将不再受支持。GitHub 将其描述为一种较慢、使用较少的旧式 Diffie-Hellman 密钥交换方法。
• 提高新 RSA 密钥的最低长度：从 2026 年 10 月 14 日起，之后上传到 GitHub 的 RSA SSH 密钥必须至少为 3072 位；这一要求同时适用于签名和身份验证。
• 增加后量子密钥交换：GitHub 将支持 mlkem768x25519-sha256，用于为 SSH 会话协商密钥。该算法面向后量子安全；密钥交换算法与用户用于身份验证的 SSH 密钥不是同一回事。

已有 RSA 密钥通常不必重建

RSA 密钥的类型与签名所用的哈希算法是两回事。名称容易混淆的地方在于：ssh-rsa 既可泛指 RSA 密钥类型，也可特指“使用 SHA-1 的 RSA 签名”。GitHub 移除的是后一种签名类型，并不意味着已有 RSA 密钥本身一律失效。

如果现有 RSA 密钥所用的 SSH 客户端或程序库支持 RSA-SHA2，通常可以继续使用原密钥，并以 rsa-sha2-256 或 rsa-sha2-512 签名。GitHub 表示，大多数支持 RSA-SHA2 的 SSH 实现会在默认情况下自动选择相应签名。新 RSA 密钥的 3072 位要求针对 2026 年 10 月 14 日起上传的密钥，不代表现有密钥届时都必须更换。

如果使用的旧软件无法升级，可以考虑改用 GitHub 支持的 Ed25519 或 ECDSA 密钥；GitHub 表示，这两类密钥将继续受支持。新建密钥时，GitHub 建议在条件允许的情况下优先选择 Ed25519。若因其他服务的兼容性要求必须使用 RSA，则新密钥至少应为 3072 位。

生效时间与不同 GitHub 产品的安排

• 2026 年 10 月 14 日：新上传 RSA SSH 密钥的最低长度要求生效。mlkem768x25519-sha256 也将在 github.com 和 GitHub Enterprise Cloud with Data Residency 启用，但美国区域除外。
• 2026 年 11 月 4 日：对 SHA-1 RSA 签名类型 ssh-rsa 和密钥交换算法 diffie-hellman-group-exchange-sha256 进行一次 brownout（短时禁用），用于暴露依赖这些算法的连接问题。
• 2026 年 12 月 9 日：对这两项算法进行第二次 brownout。
• 2027 年 1 月 13 日：正式移除这两项算法。

对于 GitHub Enterprise Server，除新增后量子密钥交换算法外，这些调整将在 3.25 版本生效；mlkem768x25519-sha256 则将在 3.24 版本生效。这里的版本号对应 GitHub Enterprise Server 产品版本，不应与 github.com 或 GitHub Enterprise Cloud 的日期安排混为一谈。

哪些连接方式会受影响

主要受影响的是通过 SSH 使用 Git 的用户，以及在 GitHub Enterprise Server 上使用未认证 Git 协议的用户。可以先检查仓库远程地址：以 https:// 开头的地址使用 HTTPS，不受这次 SSH 算法调整影响；通过 SSH 连接的地址则需要确认客户端和相关程序库能否使用仍受支持的算法。

如果组织使用脚本、自动化任务或其他集成程序访问 GitHub，也应把它们使用的 SSH 客户端或程序库纳入检查范围。问题不一定出在本机交互式终端：实际发起 Git 连接的可能是独立运行的服务、构建任务或部署环境。

连接异常时如何排查

1. 先确认连接方式。检查 Git 远程地址是否使用 SSH；如果使用 HTTPS，就不必为了这次调整改动 SSH 密钥或配置。
2. 确认实际使用的客户端。运行 ssh -V 可以查看当前命令行 SSH 客户端的版本。若 Git 操作由自动化程序或其他应用发起，还要确认它们使用的 SSH 实现或程序库，因为它们未必调用终端中的同一个客户端。
3. 检查 RSA 签名支持。若使用 RSA 密钥，确认客户端或程序库支持 rsa-sha2-256、rsa-sha2-512。旧实现如果只能使用 SHA-1 的 ssh-rsa 签名，就需要升级；支持 RSA-SHA2 时，通常不必因此更换现有 RSA 密钥。
4. 检查密钥交换能力。GitHub 表示，支持 RSA-SHA2 的 SSH 实现也应支持较强的密钥交换机制。如果连接仍依赖 diffie-hellman-group-exchange-sha256，应升级到支持其他强密钥交换算法的客户端或程序库。
5. 查看连接日志和本地配置。可运行 ssh -vT git@github.com 查看 SSH 连接调试信息；日志内容会因客户端和平台而异。ssh -G github.com 可查看客户端对该主机应用的有效配置。如果配置显式限制了签名算法或密钥交换算法，检查这些限制是否排除了可用的现代选项。

升级或调整配置后，可以再次执行 ssh -T git@github.com 测试 SSH 身份验证，并进一步确认实际 Git 拉取或推送能够完成。若无法升级旧软件，Ed25519 或 ECDSA 密钥可作为替代选择；不应把强制启用 SHA-1 签名或旧式密钥交换算法作为长期绕过方案，因为它们将按计划逐步禁用并最终移除。

后量子算法是否需要手动启用

通常不需要因新增 mlkem768x25519-sha256 而修改密钥或连接配置。SSH 客户端会根据自身支持的算法和偏好参与协商：支持并优先选择该算法的客户端可以自动使用它；较旧的客户端则会自动回退到其他可用的密钥交换算法。后量子密钥交换不会取代用户用于 SSH 身份验证的密钥，也不会改变 HTTPS 远程地址的使用方式。

原始来源： https://github.blog/changelog/2026-09-22-security-improvements-for-ssh