新版 OpenSSH 连接旧服务器或网络设备时，可能在登录前就提示 no matching host key type found. Their offer: ...。这表示客户端与服务端没有共同启用的主机身份算法，故障发生在验证服务器身份的阶段，还没有进入密码或用户公钥认证。
正确做法不是关闭整个 SSH 校验，而是确认对端实际提供的算法，把兼容范围限制到这一台可信主机，并尽快升级服务端。
先读懂Their offer给出的算法
使用详细日志重试一次，并保存完整报错：
ssh -vvv user@legacy.example.com常见输出可能包含 Their offer: ssh-rsa 或 Their offer: ssh-dss。这里的名称描述服务器用于证明自身身份的主机密钥算法，不等于客户端登录时使用的私钥文件类型。OpenSSH 官方将这一阶段对应到 HostKeyAlgorithms。
还可以查询客户端支持的算法，以及连接到特定主机时最终生效的配置：
ssh -Q key
ssh -G user@legacy.example.com | grep -i '^hostkeyalgorithms'只有报错明确指向 no matching host key type found 时，才处理 HostKeyAlgorithms；不要把它与 key exchange、cipher 或用户公钥认证失败混为一谈。
为什么新版OpenSSH不再默认接受旧算法
OpenSSH 官方说明，一些旧算法仍保留用于兼容，但因已知弱点不再默认启用。ssh-dss 从 OpenSSH 7.0 起默认禁用；旧式 ssh-rsa 签名依赖 SHA-1，也已在较新的 OpenSSH 中退出默认集合。
RSA 密钥本身并不必然过时。支持现代协议的服务端可以继续使用 RSA 密钥并协商 rsa-sha2-256 或 rsa-sha2-512 签名。因此看到 ssh-rsa 报错时，应优先升级服务端，而不是误以为必须删除所有 RSA 主机密钥。
如果对端只能提供 ssh-dss，风险更高。OpenSSH 官方明确把 DSA 算法视为弱算法，兼容配置只能作为短期迁移措施。
用一次性参数验证故障判断
确认主机归属和密钥指纹后，可以只对本次命令追加报错中实际出现的算法。例如对端只提供旧式 RSA：
ssh -oHostKeyAlgorithms=+ssh-rsa user@legacy.example.com若对端只提供 DSA，测试命令可能是：
ssh -oHostKeyAlgorithms=+ssh-dss user@legacy.example.com前导 + 的含义是把算法附加到客户端默认列表末尾，而不是用弱算法列表覆盖默认值。这样当服务器支持现代算法时，客户端仍会优先选择更安全的共同算法。
首次兼容连接前必须通过控制台、资产系统或其他可信渠道核对服务器主机密钥指纹。 算法协商成功不代表对端身份自动可信，不能在来源不明时直接接受新的指纹。
把兼容范围限制到单一主机
一次性测试通过后，如短期内必须继续访问，可在 ~/.ssh/config 中为准确主机名单独配置：
Host legacy.example.com
HostName 192.0.2.20
User admin
HostKeyAlgorithms +ssh-rsa然后检查最终配置：
ssh -G legacy.example.com | grep -i '^hostkeyalgorithms'不要把弱算法写进 Host *，也不要修改系统级配置让所有用户和所有目标都接受它。最小化规则的关键是准确的 Host 条目、明确的到期时间和已核验的主机指纹。
需要在隔离环境复现旧系统时，可用 萤光云 建立测试机，或用 LightNode 临时验证客户端配置。测试环境仍应使用独立密钥，不要复制生产私钥。
从服务端消除临时兼容配置
长期修复应在服务器端完成。先确认 OpenSSH 版本和现有主机密钥：
sshd -V 2>&1 | head -1
sudo sshd -T | grep -i '^hostkey'
sudo ls -l /etc/ssh/ssh_host_*_key.pub升级 OpenSSH，并配置 Ed25519、ECDSA 或支持 RSA-SHA2 的主机密钥。修改前保留云控制台或带外管理通道，修改后先执行配置检查：
sudo sshd -t
sudo systemctl reload ssh不同发行版的服务名可能是 ssh 或 sshd。在关闭当前会话前，必须另开一个终端验证现代算法能够登录；否则一次错误配置就可能把管理员锁在服务器外。
删除例外并完成安全验收
服务端升级后，去掉客户端的 HostKeyAlgorithms 例外，再用详细日志连接：
ssh -vv user@legacy.example.com
ssh-keyscan -t ed25519 legacy.example.com核对日志中协商的主机密钥算法与资产登记的指纹。如果主机密钥确实更新，应通过可信渠道确认后再更新 known_hosts，不能为省事删除整个文件。
合格的验收标准是：默认客户端无需弱算法例外即可连接、主机指纹已经核对、旧算法规则已删除，并且备用管理通道可用。
FAQ
这个报错与Permission denied (publickey)是一回事吗？
不是。前者发生在服务器主机身份算法协商阶段，后者通常发生在用户认证阶段。两者对应的配置项和修复方向不同。
可以直接写HostKeyAlgorithms ssh-rsa吗？
不建议。没有 + 会用指定列表替换默认列表，可能反而禁止现代算法。应按官方建议使用追加方式，并限定到单一主机。
为什么加了HostKeyAlgorithms还是无法用密钥登录？
主机身份协商通过后，还可能遇到用户公钥签名算法不兼容。应根据新的明确报错判断是否涉及 PubkeyAcceptedAlgorithms，不要预先放宽所有算法。
温馨提示
弱算法兼容应当是有边界、有期限的迁移工具，而不是长期安全策略。 保存改动前后的配置和指纹记录，优先升级服务端，并始终保留一个已经验证可用的带外恢复入口。
