该警告是ssh安全机制在提示主机密钥变更，非连接故障；需先确认是否为服务器重装等合法变更，再用ssh-keygen -r安全删除known_hosts中对应记录。
这个警告不是连接失败，而是 SSH 客户端在告诉你：你曾经连过的那台机器，现在“长得不一样了”。直接删 known_hosts 里对应记录就能恢复连接，但别急着删——先确认是不是真换了机器，还是被中间人劫持了。
为什么每次重装服务器后都会触发这个警告
SSH 第一次连接某 IP 时，会把对方的主机密钥（比如 ecdsa-sha2-nistp256 或 ssh-ed25519）存进本地 ~/.ssh/known_hosts。下次再连同一 IP，就比对密钥是否一致。一旦服务器重装系统、重置 SSH 服务，或密钥被手动轮换，密钥就变了，校验就失败。
常见诱因包括：
- 云服务器重装系统镜像
- 物理机重装 OS 或重置
/etc/ssh/ssh_host_*.key - 同一 IP 被回收并分配给另一台新机器（尤其在内网或 DHCP 环境）
- 有人误操作执行了
ssh-keygen -A或删了/etc/ssh/ssh_host_*文件
用 ssh-keygen -R 安全删除旧记录
这是最推荐的方式，它只删目标 IP 的条目，不碰其他已知主机，还自动备份原 known_hosts（加 .old 后缀）。
执行命令时注意几点：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- IP 地址要写对，如果用了非标准端口，必须带端口：例如
ssh-keygen -R [192.168.1.100]:2222 - IPv6 地址必须用方括号包裹，否则会解析失败
- 如果主机名解析到多个 IP（比如 DNS 轮询），
-R只删第一个匹配项；建议优先用 IP 操作 - 删完后首次重连会提示 “Are you sure you want to continue connecting (yes/no/[fingerprint])?”，输入
yes即可存新密钥
手动编辑 known_hosts 的风险点
新版 OpenSSH 默认开启 HashKnownHosts yes，所以 known_hosts 里存的是哈希值，不是明文 IP。直接用 vim 打开看到的是类似 |1|abc...=|def...= ssh-rsa AAAA... 这样的内容，没法靠眼识别哪行对应哪个 IP。
如果你非要手动删：
- 先运行
ssh-keyscan 192.168.1.100获取该 IP 当前密钥的哈希标识（输出第一列） - 再用
grep -n "哈希串" ~/.ssh/known_hosts定位行号 - 最后用
sed -i '4d' ~/.ssh/known_hosts（假设是第 4 行）删掉——但容易误删相邻行 - 更稳妥的做法是临时关哈希：
echo "HashKnownHosts no" >> /etc/ssh/ssh_config，然后重连一次让新密钥以明文写入，再删
绕过校验的命令参数不能乱用
像 ssh -o StrictHostKeyChecking=no user@host 或 -o UserKnownHostsFile=/dev/null 这类参数，确实能跳过警告，但等于主动关闭 SSH 最基础的身份认证防线。
它们只适合极少数场景：
- CI/CD 流水线中连接临时测试机（且网络完全可信）
- 自动化脚本调试阶段，且明确知道目标机器生命周期极短
- 绝对不要在日常运维、生产环境或任何含敏感数据的连接中启用
真正容易被忽略的细节是：警告本身不是 bug，它是 SSH 设计里最关键的防中间人攻击机制。删记录前，最好通过其他通道（比如 VNC、控制台、同事确认）核对下服务器当前密钥指纹，哪怕只多花 10 秒。
