必须显式配置sshd_config的KexAlgorithms、Ciphers、Macs和HostKeyAlgorithms四参数，仅保留curve25519-sha26、aes256-gcm@openssh.com等强算法及ssh-ed25519/rsa-sha2-512，同步生成对应ed25519或RSA-4096 HostKey文件，并用sshd -t验证后reload。
只允许 Ed25519 或 RSA-4096，必须改 sshd_config 的 KexAlgorithms、Ciphers、Macs 和 HostKeyAlgorithms
OpenSSH 默认会启用一堆算法（包括老旧不安全的），但“只用 Ed25519 或 RSA-4096”不是指密钥类型，而是指整个 SSH 协议握手阶段的算法组合。光生成 id_ed25519 不够，服务端必须明确拒绝弱算法，否则客户端仍可能降级协商出 ssh-rsa（已被 OpenSSH 8.8+ 默认禁用签名）或 diffie-hellman-group1-sha1 等已弃用项。
关键配置项要一起收紧：
-
KexAlgorithms：只保留现代密钥交换，例如curve25519-sha256,ecdh-sha2-nistp521（禁用所有dh和group1/14） -
Ciphers：禁用cbc模式和arcfour，只留aes256-gcm@openssh.com,chacha20-poly1305@openssh.com -
Macs：只留hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com -
HostKeyAlgorithms：这是重点——控制服务器用哪种密钥做主机认证，必须显式列出ssh-ed25519,rsa-sha2-512,rsa-sha2-256，并**去掉ssh-rsa**（OpenSSH 8.8+ 已默认不接受该签名）
改完后务必运行 sudo sshd -t 检查语法，再 sudo systemctl reload sshd（不要直接 restart，避免连接中断）。
服务器端 HostKey 必须包含 Ed25519 或 RSA-4096 密钥文件
即使 HostKeyAlgorithms 列了 ssh-ed25519，如果 /etc/ssh/ssh_host_ed25519_key 文件不存在，sshd 启动时会静默跳过，回退到其他可用 HostKey（比如残留的 ssh_host_rsa_key，若它只有 2048 位就违规）。
确认并生成合规 HostKey：
- 检查现有密钥：
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key 2>/dev/null || echo "missing ed25519" - 生成 Ed25519 HostKey：
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" - 生成 RSA-4096 HostKey（仅当必须兼容旧客户端）：
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" - 删掉不合规的旧密钥（如
ssh_host_rsa_key是 2048 位）：sudo rm /etc/ssh/ssh_host_rsa_key*
注意：-N "" 表示无密码，因为 HostKey 是系统自动加载的，不能设口令。
客户端连接时被拒？大概率是算法协商失败，不是密钥问题
常见错误信息如：no matching host key type found. Their offer: ssh-rsa 或 no matching key exchange method found，说明客户端和服务端在 HostKeyAlgorithms 或 KexAlgorithms 上完全对不上。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
临时调试方法（不推荐长期使用）：
- 客户端强制指定算法测试：
ssh -o HostKeyAlgorithms=ssh-ed25519 user@host - 查看服务端实际支持的算法：
ssh -vvv user@host 2>&1 | grep "server offers"（找kex、hostkey相关行） - 别用老版本 OpenSSH 客户端（如 CentOS 7 自带的 7.4p1），它根本不认识
ssh-ed25519；升级到 OpenSSH 7.8+ 更稳妥
真实环境中，客户端通常不需要额外配置——只要服务端算法列表干净、HostKey 存在且权限正确（/etc/ssh/ssh_host_*.key 必须是 root:root 且权限 600），新客户端就能自动协商成功。
为什么不能只改 PubkeyAuthentication 就算“只用 Ed25519”？
PubkeyAuthentication yes 只控制用户认证是否允许公钥登录，跟服务端用什么算法做主机认证、密钥交换、加密完全无关。它不干预 ssh-rsa 主机密钥继续被使用，也不阻止客户端用弱 cipher 连接。
真正实现“只用 Ed25519 或 RSA-4096”的硬约束，在于四组算法参数的显式声明 + 对应 HostKey 文件的存在与权限。漏掉任意一环，都可能让漏洞或降级攻击有机可乘。
最容易被忽略的是：改完 sshd_config 后没生成对应 HostKey 文件，或者忘了 sshd -t 验证就 reload，结果服务静默降级到备用算法——而你根本不会收到任何告警。
