ssh-audit通过连接目标SSH服务并解析其真实协商能力（KexAlgorithms、Ciphers、MACs列表），比对内置安全数据库（如ssh2_kexdb.py）识别弱算法，如aes128-cbc、3des-cbc等，并标注❌警告；它不修改配置，仅提供禁用/启用建议。
能直接检测并给出修复路径，但 ssh-audit 本身不改配置——它只告诉你哪些算法该禁用、哪些该启用。
ssh-audit 怎么识别弱加密算法
它不是靠猜，而是连接目标 SSH 服务后，解析真实协商能力：抓取服务端返回的 KexAlgorithms、Ciphers、MACs 列表，再逐条比对内置数据库（src/ssh_audit/ssh2_kexdb.py）里的安全评级。
常见被标为 ❌ 的弱加密算法包括：
-
aes128-cbc、aes256-cbc（CBC 模式易受填充预言攻击） -
3des-cbc（Sweet32 攻击可破解） -
arcfour、arcfour128（密钥流偏差严重） -
blowfish-cbc（64 位块大小已过时）
执行命令后，你会看到类似这样的输出：
encryption_algorithms (8) aes128-cbc -- [WARN] deprecated cipher aes256-cbc -- [WARN] deprecated cipher chacha20-poly1305@openssh.com -- [INFO] available since OpenSSH 6.5
为什么 -b 批量模式 + grep 更适合运维排查
单台服务器用 ssh-audit example.com 看报告很直观，但批量扫几十上百台时，人工翻绿色/红色太慢。这时候必须用 -b（batch mode）输出结构化文本，再配合 grep 或 awk 提取关键项。
-
python ssh-audit.py -b 192.168.1.10 | grep 'ciphers:'直接定位加密算法行 -
python ssh-audit.py -b serverX | awk -F': ' '/ciphers:/ {print $2}' | tr ',' '\n' | grep -E '(cbc|3des|arcfour)'精准筛出所有弱 cipher - 别漏掉
mac_algorithms和kex_algorithms，它们同样有hmac-md5、diffie-hellman-group1-sha1这类高危项
注意：-b 模式默认不显示警告原因，要确认某算法为何被标红，得加 -v 单独重跑一次。
修复时最常踩的坑：配置覆盖顺序和重启验证
很多人改完 /etc/ssh/sshd_config 就以为完事了，结果 sshd -T 显示的还是旧算法——问题往往出在策略覆盖上。
- 检查是否存在
/etc/crypto-policies/back-ends/opensshserver.config，它会**完全覆盖**sshd_config中的Ciphers等设置（尤其在 RHEL/CentOS 8+、Fedora） - 运行
sshd -T | grep -E 'ciphers|macs|kex'，看实际生效值。如果输出里还有aes128-cbc，说明配置没生效或被策略劫持 - 修改后必须用
sudo systemctl restart sshd，不能只 reload（部分老版本 OpenSSH reload 不重读加密参数） - 验证是否真正禁用：用
ssh -oCiphers=+aes128-cbc user@host强制启用弱算法，应直接报错连接失败
客户端侧也得同步加固
服务器端修好了，但管理员本地 ssh 命令仍可能主动提议弱算法，等于留了后门。需检查：
- 全局客户端配置：
/etc/ssh/ssh_config中的Ciphers、KexAlgorithms - 用户级配置：
~/.ssh/config是否存在Host *下的宽松算法设置 - 临时测试命令：
ssh -Q cipher查看本机支持的所有 cipher，确认没有3des-cbc等残留
客户端加固的关键是「主动收紧」，而不是等服务器拒绝——因为有些老旧服务器不支持新算法，但你的客户端不该主动降级。
真正的难点不在工具使用，而在于平衡：禁用弱算法后，会不会导致某些嵌入式设备、IoT 终端或遗留系统彻底无法连接？这类兼容性断点必须提前在非生产环境验证，不能只依赖 ssh-audit 的“安全建议”就一刀切。
