macOS 自带 OpenSSH 8.8+ 默认禁用 ssh-rsa 等老旧算法，导致连接旧设备时出现密钥、加密、MAC 或密钥交换不匹配错误；应通过命令行参数或 ~/.ssh/config 按需启用对应算法，避免全局降级。
macos 自带的 openssh 客户端从 8.8 版本起（2021 年 8 月后）默认禁用 ssh-rsa 主机密钥算法，同时逐步移除对 diffie-hellman-group1-sha1、aes128-cbc、hmac-md5 等老旧算法的支持。当你用较新 macos（如 ventura、sonoma 或 sequoia）连接老设备、嵌入式系统、旧版 linux 服务器或网络设备时，就容易出现类似以下错误：
Unable to negotiate with 192.168.1.100 port 22: no matching host key type found
no matching cipher found
no matching MAC found
algorithm negotiation failed
这些不是网络问题，也不是密码或密钥错了，而是客户端和服务器在“握手阶段”根本没聊拢用什么加密方式——连接还没走到认证那步就断了。
临时连一次：命令行加参数最直接
适合快速登录老设备执行命令、传文件或紧急排查。不用改配置，不污染环境：
- 如果报 no matching host key type（常见于 OpenSSH ≥8.8）：
ssh -o HostKeyAlgorithms=+ssh-rsa user@host - 如果报 no matching cipher（比如服务器只支持
aes128-cbc）：ssh -o Ciphers=+aes128-cbc user@host - 如果报 no matching MAC（比如服务器只提供
hmac-sha1）：ssh -o MACs=+hmac-sha1 user@host - 如果报 no matching kex algorithm（比如只支持
diffie-hellman-group1-sha1）：ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 user@host
多个问题可组合使用，例如：ssh -o HostKeyAlgorithms=+ssh-rsa -o Ciphers=+aes128-cbc -o MACs=+hmac-sha1 -o KexAlgorithms=+diffie-hellman-group1-sha1 user@host
长期用一批老设备：配 ~/.ssh/config 更省事
编辑用户级 SSH 配置文件：vi ~/.ssh/config
在文件末尾添加一段主机别名配置，例如：
Host legacy-server
HostName 192.168.1.100
User admin
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Ciphers +aes128-cbc,aes256-cbc,3des-cbc
MACs +hmac-sha1,hmac-md5
KexAlgorithms +diffie-hellman-group1-sha1
之后只需运行 ssh legacy-server，所有兼容参数自动生效。不同设备可定义不同 Host 段，互不干扰。
注意安全边界：别全局放开，按需启用
不建议在 /etc/ssh/ssh_config 或全局配置里无差别启用老旧算法，这会降低所有连接的安全水位。只针对明确已知的老旧目标启用，并标注注释，例如：
# ⚠️ 仅用于连接 2012 年产交换机（固件不可升级）
Host sw-core-01
HostName 10.10.5.1
HostKeyAlgorithms +ssh-rsa
KexAlgorithms +diffie-hellman-group1-sha1
完成关键操作后，可随时注释掉对应段落恢复默认策略。
进阶建议：优先考虑升级或代理中转
若管理大量老旧资产，长期靠降级算法不是长久之计。可考虑：
- 用一台中间跳板机（如 Ubuntu 20.04 虚拟机），装旧版 OpenSSH（如 7.2），专门负责连老设备；macOS 只连跳板机（走现代算法）
- 对支持 WebSSH 的设备，改用浏览器访问，绕过本地 SSH 协商
- 联系厂商确认是否有固件更新，或能否启用更安全的替代算法（如 ecdsa-sha2-nistp256）
macOS 上的 SSH 算法不匹配问题本质是安全演进带来的兼容性阵痛。理解“哪里卡住、为什么卡、怎么精准松绑”，比盲目改全局配置更可靠也更安全。
