WSL2环境下因服务器重装引发的SSH连接问题排查记录

背景

近期在重装一台云服务器后，我尝试从本地的WSL2环境通过SSH连接，遇到了连接失败的问题。我的工作环境组合比较典型：SSH密钥对存放在Windows原生系统下（C:\Users\YourUser\.ssh），而日常的终端操作则在WSL2中完成。本文旨在记录该问题的排查过程和最终采用的优化方案。

1. 初步尝试：指定密钥路径连接

服务器重装后，需要将本地的SSH公钥重新部署到服务器的authorized_keys文件中。在WSL2终端中，直接执行 ssh-copy-id 无法访问到位于Windows文件系统中的密钥。

解决方案是利用WSL的挂载机制，通过/mnt/路径访问Windows磁盘，并使用 ssh-copy-id 的 -i 参数来指定公钥的具体位置。

bash 复制代码

# -i 参数用于指定身份文件（公钥）
ssh-copy-id -i /mnt/c/Users/我真棒/.ssh/id_rsa.pub root@38.55.178.244

2. 发现问题：主机密钥验证失败

执行上述命令后，连接并未成功，终端返回了关于主机身份识别变更的警告：

复制代码

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
...
Host key verification failed.

这个警告是SSH的一项核心安全特性。SSH客户端会在本地的 ~/.ssh/known_hosts 文件中缓存已连接过的服务器的主机公钥指纹。当客户端再次连接同一IP或域名的服务器时，会校验收到的公钥指纹是否与本地记录一致。

由于我重装了服务器系统，服务器端的SSH服务重新生成了一对主机密钥，导致其指纹发生了变化。客户端检测到这一不匹配，出于防止中间人攻击的考虑，默认中断了连接。

3. 解决问题：更新本地主机记录

确认主机密钥变更是由我方正常操作（重装系统）引起后，需要更新本地的 known_hosts 文件。手动编辑该文件容易出错，推荐使用 ssh-keygen 工具进行管理。警告信息中也提示了标准的操作命令：

bash 复制代码

ssh-keygen -f "/home/oi/.ssh/known_hosts" -R "38.55.178.244"

该命令会精确地移除指定IP地址的旧记录，而不影响文件中其他主机的条目。

清除旧记录后，再次执行第一步中的 ssh-copy-id 命令。此时，终端会提示无法确认主机的真实性，并询问是否继续连接。输入 yes 后，新的主机密钥指纹将被保存到 known_hosts 文件中，随后按提示输入密码即可完成公钥的部署。

测试连接发现也是能成功连接上

4. 优化工作流：统一SSH配置

虽然连接问题得以解决，但每次操作都需要手动指定位于Windows下的密钥路径，操作上较为繁琐。为了优化日常工作流，我决定统一Windows与WSL2的SSH配置。

我采用的方法是在WSL2中创建符号链接，使其 ~/.ssh 目录直接指向Windows下的对应目录。

操作步骤：

创建符号链接

bash 复制代码

ln -s /mnt/c/Users/我真棒/.ssh ~/.ssh

修正目录和文件权限

这是非常关键的一步。由于Windows和Linux的文件权限系统不同，直接链接后可能导致权限过于开放，SSH会因此拒绝使用这些密钥。必须手动设置为SSH要求的严格权限。
bash 复制代码
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
```

完成配置后，WSL2中的所有SSH相关命令将默认使用Windows目录下的密钥和配置，实现了两个环境身份的统一，简化了后续操作。