身份与供应链变化解读

GitHub SSH 新规：密钥太短、ssh-rsa 和认证失败怎么查

添加密钥时报 Key is too short，与连接时的 Permission denied (publickey) 不是同一个问题。先找到失败发生在哪一步，再检查密钥、客户端或账户。

Zhengjim AI 编辑 · 发布 2026-10-26 · 核实 2026-10-27 · 原始公告 2026-09-22 · 约 4 分钟

要点

新 RSA 密钥上传长度、SSH 签名算法和账户认证要分别检查。看到 RSA 公钥，不代表它只能用 SHA-1。

先看接下来几个日期

GitHub 已要求新上传的 RSA 密钥至少为 3072 位。旧签名与密钥交换算法的移除还有后续演练，使用老客户端、旧 CI 镜像或内置 SSH 库的团队，需要提前检查。

这个报错通常出现在添加或上传密钥时。先确认是谁生成了这把公钥、它有多少位，以及部署工具是否正尝试把它添加到另一个仓库。

DeployHQ 的排障文档提到，部分旧项目的密钥仍能用于已经绑定的仓库，但新增仓库绑定时会被长度校验拒绝。遇到这种情况，要处理的是新绑定所用的密钥，不能据此推断原有部署全部失效。

换钥之前列清它还用在哪里。部署平台可能用同一把项目密钥连接多台服务器，改完一处却漏掉其他入口，会造成新的连接故障。

这次移除涉及使用 SHA-1 的 ssh-rsa 签名等能力。RSA 密钥本身也可以配合 SHA-2 签名，关键在实际连接程序支持并使用了哪种算法。

需要检查的是执行任务的那套客户端或库。开发机连接正常，不能说明 runner 镜像、备份脚本或某个应用内置的 SSH 库也已兼容。使用 HTTPS 的 Git remote 不属于这次 SSH 调整的影响范围。

这是认证被拒的提示。GitHub 的排障步骤包括检查连接目标、git 用户、实际选中的密钥，以及公钥是否关联正确账户。这一行提示不足以确定是本次算法调整导致。

失败位置	先查什么
添加公钥时被拒	新上传密钥的类型、长度和生成工具
连接时没有共同算法	原始错误指向的算法类型，以及客户端或库版本
Permission denied (publickey)	连接身份、选中的密钥、公钥与账户的关联

从一条发布或备份任务开始，把下面的信息填齐，再验证下一条。记录里不需要私钥；分享日志时也应移除凭据和内部地址。

记录项	需要写下什么
任务	任务名、用途、维护人和触发方式
连接	目标域名，使用 SSH 还是 HTTPS
程序	真正发起连接的客户端或库、版本和运行镜像
密钥	用于认证还是签名，关联哪个账户或仓库，还有哪些共用入口
故障	失败发生在哪一步，原始错误是什么
变更	改了什么、谁负责、失败时如何恢复
结果	实际任务何时运行、是否成功，还有什么没验证

依据文末资料整理，未做环境实测。编辑与更正说明。

2026-10-26：首次发布：梳理 GitHub 官方 SSH 调整时间表与迁移范围。

2026-10-27：补充密钥上传被拒、协商失败与身份认证的分支解释，以及按工作流填写的迁移记录表；新增 DeployHQ 与 GitHub 排障来源，保留原 URL 和首发日期。

2026-10-27：编辑修订：重写标题、导语和正文，删去重复提示，保留技术范围、来源与原发布时间。