核心是显式声明强算法白名单并同步收紧协议层与密钥交换：ciphers、kexalgorithms、macs三参数必须全部配置，禁用所有cbc、sha1、md5及非etm后缀项，通过sshd -t验证后reload服务。
Linux 中配置 SSH 服务拒绝弱密码套件，核心不是简单删掉几行配置，而是精准控制加密算法协商过程——OpenSSH 默认会按客户端能力“降级匹配”，哪怕你写了 Ciphers，只要客户端还支持 arcfour 或 3des-cbc，服务端就可能妥协握手。真正有效的做法是显式声明强算法白名单，并配合协议层与密钥交换机制同步收紧。
确认当前启用的加密套件
先摸清现状，避免误禁导致连接中断：
- 在服务器上执行：
sshd -T | grep -E "(ciphers|kexalgorithms|macs)"，查看当前生效的加密、密钥交换和消息认证算法 - 用客户端主动探测支持项：
ssh -Q cipher user@server和ssh -Q kex user@server，比对哪些弱算法仍被列出（如arcfour256、blowfish-cbc、3des-cbc、diffie-hellman-group1-sha1） - 重点识别已被 NIST 或 CIS 基线明确弃用的算法：所有
cbc后缀的对称加密、sha1结尾的 KEX、hmac-md5类 MAC
编辑 sshd_config 强制启用现代算法
打开 /etc/ssh/sshd_config，添加或修改以下三组参数（推荐放在文件末尾，避免被前面注释覆盖）：
-
加密算法（Ciphers）：
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr -
密钥交换（KexAlgorithms）：
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 -
消息认证（MACs）：
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
注意：全部使用 etm@openssh.com（encrypt-then-MAC）后缀的 MAC，它比传统 MAC 更安全；禁用所有 cbc、sha1、md5 相关项。
验证语法并安全重启
改完不直接重启，防止配置错误锁死连接：
- 运行
sudo sshd -t检查语法，无输出即通过 - 用新终端测试连接：
ssh -o Ciphers=aes256-gcm@openssh.com user@server，确认能连通 - 再试一个已知弱算法：
ssh -o Ciphers=3des-cbc user@server，应报错“no matching cipher found” - 确认无误后执行：
sudo systemctl restart sshd
兼容旧客户端的灰度策略（可选）
若存在 Java 7、老旧嵌入式设备等必须连入的客户端，不要全局放开弱算法，而是用 Match 块做条件控制：
- 例如只给内网监控系统保留
aes128-ctr：Match Address 192.168.10.0/24<br> Ciphers aes128-ctr,chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
- 公网入口则严格限制：
Match Address 0.0.0.0/0<br> Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
这样既满足业务连续性，又守住边界安全底线。
