根本原因是~/.ssh/known_hosts中旧密钥与服务器变更后的密钥不匹配，sequoia对哈希格式、端口标识、文件权限及符号链接更严格，导致ssh-keygen -r删除失效或openssh静默拒绝读取。
Navicat 在 macOS Sequoia 上报 “Host key verification failed” 错误，根本原因是 ~/.ssh/known_hosts 里存了旧密钥，而目标服务器密钥已变更（比如重装系统、更换 SSH 服务、升级 OpenSSH），Navicat 调用的底层 OpenSSH 拒绝继续连接——这不是 Navicat 的 bug，而是安全机制在起作用。
为什么 ssh-keygen -R 不总能立刻生效
Sequoia 对 known_hosts 的读取逻辑更严格，尤其当条目含端口（如 [example.com]:2222）或使用哈希格式（HashKnownHosts yes）时，ssh-keygen -R example.com 可能找不到匹配行。
- 先确认实际存储格式：
head -n 3 ~/.ssh/known_hosts—— 若首行是|1|...开头，说明启用了哈希，必须用完整哈希键删除：ssh-keygen -R "[example.com]:2222"（注意方括号和端口） - 若删完仍报错，检查是否用了别名：Navicat SSH 设置中填的是
jump.example.com，但known_hosts里存的是 IP，得用ssh-keygen -R 192.168.1.100再试 - Sequoia 下部分终端会缓存 DNS 解析结果，可加
-o ConnectTimeout=5强制刷新，避免误判主机变更
Navicat 自身不读取 known_hosts 的常见误解
Navicat 并不直接解析 known_hosts 文件，它调用系统 ssh 命令建立隧道，而该命令依赖 OpenSSH 的默认行为。所以问题不在 Navicat 配置页，而在系统级 SSH 环境。
- 不要在 Navicat SSH 设置里勾选“验证主机密钥”之类选项——它没有这个开关，所有验证都由系统
ssh完成 - 如果改过
/etc/ssh/ssh_config或~/.ssh/config，检查是否有StrictHostKeyChecking no这类临时绕过项，Sequoia 会忽略它们或报 warning，反而让连接卡住 - 执行
ssh -T -p 22 user@host手动测试，若同样失败，说明是纯 SSH 层问题，和 Navicat 无关
Sequoia 特有的权限与路径陷阱
Sequoia 加强了对用户目录符号链接和 ACL 权限的校验，known_hosts 文件若权限不对或路径含软链，OpenSSH 会静默拒绝读取，导致 Navicat 连接超时而非报密钥错误。
- 运行
ls -l ~/.ssh/known_hosts—— 正确权限必须是-rw-------@（末尾 @ 表示有扩展属性，正常）；若显示rw-r--r--，立刻执行：chmod 600 ~/.ssh/known_hosts - 避免路径含符号链接：
cd ~/.ssh && pwd -P看是否输出真实路径；若为/Users/me/Dropbox/.ssh这类同步目录，Sequoia 可能因 iCloud 或 Dropbox 的文件锁阻塞读写，建议迁回/Users/me/.ssh - Navicat 启动时若检测到
known_hosts不可读，会 fallback 到空信任状态，但某些版本（如 16.0.10）在 Sequoia 下会卡在“正在建立隧道”，需强制 kill 后重试
真正麻烦的不是删哪一行，而是 Sequoia 把“密钥不匹配”和“文件不可读”两种错误都折叠成同一个报错提示——务必先用命令行复现问题，再定位到底是密钥变了，还是系统拦住了读取。
