生产环境中1024位RSA密钥已不可用,必须执行“识别→停用→切换→验证”闭环:遍历用户目录、服务路径及HostKey定位残留密钥,生成4096位RSA或Ed25519新密钥并安全替换,同步升级服务端HostKey,客户端强制禁用ssh-rsa算法,确保全链路协议级安全对齐。

直接用 ssh-keygen -t rsa -b 4096 生成新密钥只是第一步。要真正完成生产环境里1024位RSA老密钥的系统性替换,关键不在“生成”,而在“识别→停用→切换→验证”闭环。OpenSSH 8.8+(Ubuntu 22.04+、CentOS Stream 9+等主流发行版已默认搭载)已将 ssh-rsa(SHA-1签名)标记为 deprecated,1024位密钥更被NIST明令淘汰——它不只是弱,而是已被协议层静默拒绝。
先定位所有残留的1024位RSA密钥
别只查 ~/.ssh/id_rsa。生产环境常存在多用户、多服务、多路径密钥:
- 遍历全部用户家目录:
find /home -maxdepth 2 -name "id_rsa" -type f -exec ssh-keygen -lf {} \; 2>/dev/null | grep " 1024 " - 检查系统级 SSH 配置中指定的 HostKey:
grep -i "hostkey" /etc/ssh/sshd_config,再对对应文件运行ssh-keygen -lf - 排查 cron、systemd service、CI/CD runner 使用的专用密钥(如
/var/lib/jenkins/.ssh/、/opt/gitlab/.ssh/)
批量停用并替换用户侧登录密钥
对每个确认为1024位的 id_rsa,执行标准化替换流程:
- 生成新密钥:
ssh-keygen -t rsa -b 4096 -C "prod-user@company.com" -f ~/.ssh/id_rsa_4096(不覆盖原文件,避免中断) - 将新公钥追加进
authorized_keys:cat ~/.ssh/id_rsa_4096.pub >> ~/.ssh/authorized_keys - 测试新密钥可登录后,从
authorized_keys中删除旧公钥行(建议先注释掉,观察24小时) - 设置严格权限:
chmod 600 ~/.ssh/id_rsa_4096 ~/.ssh/authorized_keys && chmod 700 ~/.ssh
服务端HostKey必须同步升级
如果 sshd 仍在用1024位 host key,客户端即使有强用户密钥,也会因服务端签名不安全而触发警告甚至拒绝连接:
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
- 生成新 host key:
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""(-N "" 表示空密码,适合 host key) - 更新配置确保启用:
echo "HostKey /etc/ssh/ssh_host_rsa_key" | sudo tee -a /etc/ssh/sshd_config - 重启服务:
sudo systemctl restart sshd,并验证:ssh -o HostKeyAlgorithms=+ssh-rsa example.com 2>&1 | grep "debug1: Server host key:"确认显示的是 4096 位
强制客户端拒绝旧密钥,防回退
仅服务端升级不够。需在客户端(如跳板机、运维终端)主动屏蔽过时算法,避免误用:
- 编辑
/etc/ssh/ssh_config或~/.ssh/config,添加全局限制:
Host *
PubkeyAcceptedAlgorithms +ssh-ed25519,sk-ssh-ed25519@openssh.com
PubkeyAcceptedAlgorithms -ssh-rsa - 该配置会显式禁用 ssh-rsa(即所有 RSA-SHA1),迫使客户端优先使用 ed25519 或 RSA-SHA2(需 OpenSSH ≥ 8.2)
- 验证是否生效:
ssh -vvv target-host 2>&1 | grep "pubkey algorithm",输出中不应出现ssh-rsa
这不是一次简单的密钥重生成操作,而是一次面向协议栈底层的安全策略对齐。1024位RSA已不是“够用”,而是“不可用”。用 -b 4096 是底线,但真正落地需要穿透用户、服务、客户端三层密钥生命周期。










