应显式配置KexAlgorithms为curve25519-sha26,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256，禁用所有sha1算法，重载sshd后用sshd -T验证生效。
直接禁用弱密钥交换协议，关键不是“删掉几个算法”，而是显式指定一整套现代、安全且兼容性合理的 KexAlgorithms 列表，并确保它真正生效。很多用户改完配置却没起效，问题常出在没重载服务、配置被覆盖，或写法不规范。
先确认当前实际启用的KEX算法
别只看配置文件——运行中的 sshd 才是真实权威：
- 执行 sshd -T | grep kexalgorithms，输出的是当前正在使用的完整列表
- 如果结果里含 diffie-hellman-group1-sha1 或 diffie-hellman-group14-sha1，说明弱算法仍在启用中
- 客户端连接时加 ssh -vvv user@host，在日志里搜 debug1: kex: algorithm:，可看到本次协商实际选中的算法
正确配置KexAlgorithms参数
必须顶格写一行，逗号后不加空格，不能换行，且要覆盖所有旧配置（不要保留原来的 KexAlgorithms 行）：
- 推荐值（兼顾安全与主流兼容）：
KexAlgorithms curve25519-sha26,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256 - 必须排除所有带 sha1 后缀的算法（如 group14-sha1），NIST 和 CISA 已明确弃用
- 不建议单独留 curve25519-sha256 —— 它虽快且强，但 PuTTY 0.70 以下、JSch 0.1.55 以前等老客户端不支持，会导致连接失败
- 避免使用 group16-sha512 或 group18 —— 兼容性差，多数嵌入式设备或旧工具无法识别
改完必须验证并重载，不能跳步
配置错误会直接导致 SSH 登录失败，务必按顺序操作：
- 语法检查：sudo sshd -t —— 无任何输出才表示配置合法
- 重载服务：sudo systemctl reload sshd（不是 restart，避免断开当前连接）
- 立即验证：sshd -T | grep kexalgorithms 确认输出已更新，不含 sha1 类算法
- 远程测试：从另一台机器执行 ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 user@server，应报错拒绝 —— 这说明弱算法确实已被屏蔽
顺便检查是否还有其他风险点
KexAlgorithms 只是加固的一环，顺手确认这几项能避免“只堵一扇窗，漏了整面墙”：
- Protocol 2 —— 确保配置文件中没有 Protocol 1 或 1,2，SSHv1 已彻底淘汰
- HostKey —— 删除所有 ssh_host_rsa_key（除非是 3072 位以上），优先启用 ssh_host_ed25519_key
- Ciphers 和 MACs —— 同样需显式配置，禁用 cbc、arcfour、3des、md5/sha1 非-etm 类算法
