运维安全： SSH 公钥认证算法加固

前言:SSH 是运维日常，但你可能没注意到，陪伴我们是运维日常，但你可能没注意到，陪伴我们多年的 ssh-rsa 算法，早已因 SHA-1 漏洞成为潜在风险------哪怕是内网服务器也不例外。本文从版本兼容到生产实操，带你一步步完成 SSH 算法安全加固，避开配置陷阱，让服务器连接更安全。

算法历史与安全缺陷
ssh-rsa 是早期 SSH 协议默认公钥认证算法，基于 RSA 搭配 SHA-1 哈希函数 实现；而 SHA-1 已于2017年被证实存在碰撞攻击漏洞，攻击者可伪造合法签名绕过认证，即便高强度 RSA 密钥，也会因哈希层漏洞失去安全保障。

现代安全替代方案为 rsa-sha2-256/rsa-sha2-512（RSA 搭配 SHA-2 哈希）和 Ed25519（椭圆曲线算法），其中 Ed25519 以256位密钥实现3072位 RSA 的安全强度，且性能更优。
内网服务器的安全误区

内网并非绝对安全，内部恶意人员、被钓鱼入侵的终端，或突破外网的攻击者，均可利用 ssh-rsa 漏洞发起攻击；算法本身的缺陷与网络环境无关，禁用不安全算法是服务器基础防护要求。

修改配置前必须完成三项检查，避免因版本不兼容、算法不匹配导致服务器连接中断。

查看服务器端生效公钥算法

bash 复制代码

# 查看sshd服务当前允许的公钥算法
sshd -T | grep pubkeyacceptedkeytypes
# 查看服务器端SSH客户端支持的算法
ssh -Q key

检查服务器 OpenSSH 版本（关键）
该步骤直接决定后续配置写法，是避坑核心：
bash 复制代码
```
ssh -V
```
查看本地客户端算法支持
在本地终端执行，确认 Xshell、MobaXterm 等工具的算法兼容情况：
bash 复制代码
```
ssh -Q key
```

核心目标 ：禁用不安全的 ssh-rsa，保留现代安全算法，配置写法需严格匹配 OpenSSH 版本。

编辑 SSH 服务配置文件
bash 复制代码
```
sudo vim /etc/ssh/sshd_config
```
按 OpenSSH 版本选择配置
- 现代系统（OpenSSH ≥ 7.6）
  
  适用：Ubuntu 20.04+、Rocky Linux 8+、CentOS Stream 8+ 等主流发行版
  bash 复制代码
```
# 黑名单模式：仅禁用ssh-rsa，保留其他安全算法
PubkeyAcceptedKeyTypes -ssh-rsa
```
  💡 说明：带-前缀为黑名单语法，配置简洁，无需手动列出所有算法，默认保留系统支持的安全类型。
- 老版本系统（OpenSSH < 7.6）
  
  适用：CentOS 7、Ubuntu 18.04 等（不支持黑名单语法）
  bash 复制代码
```
# 白名单模式：仅允许指定安全算法，默认禁用所有未列出算法
PubkeyAcceptedKeyTypes rsa-sha2-256,rsa-sha2-512,ssh-ed25519,ecdsa-sha2-nistp256
```
  💡 说明：需确保列出团队所需的所有安全算法，避免遗漏导致合法连接失败。
验证配置语法正确性
bash 复制代码
```
sudo sshd -t
```
无任何输出即表示语法正确，若有报错需立即检查配置写法。
重启 SSH 服务使配置生效
bash 复制代码
```
sudo systemctl restart sshd
```

配置生效后需在测试环境完成全场景验证，避免直接上线导致生产事故。

主流终端工具算法兼容表

验证配置生效与算法协商

本地执行带调试日志的连接命令，查看实际使用的算法，确认配置生效：
bash 复制代码
```
# 替换为实际服务器用户名和IP
ssh -vvv 用户名@服务器IP 2>&1 | grep "algorithm selection"
```

配置备份 ：修改前先备份原配置文件，避免配置错误导致无法连接：cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak；
版本先行 ：务必先执行ssh -V检查版本，再选择配置写法，杜绝语法错误；
灰度发布：先在测试环境验证，再在非核心生产服务器测试，最后全量推广；
工具统一：推动团队升级至 Xshell 8 或使用 MobaXterm，解决旧版工具兼容性问题；
密钥迭代：逐步将现有 RSA 密钥替换为 Ed25519 密钥，进一步提升认证安全性。

本次实操核心解决了 ssh-rsa 算法的 SHA-1 漏洞风险，同时兼顾了不同系统 OpenSSH 版本的配置兼容性，实现了 SSH 认证的基础安全加固。

后续运维工作中，建议做好两点：

SSH 安全加固并非一次性操作，只有从算法、配置、工具多维度把控，才能让服务器连接更安全。

最后不得不吐糟下AI提供的错误参数

这样会触发 OpenSSH 的解析逻辑错误：