背景
近期在重装一台云服务器后，我尝试从本地的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 参数来指定公钥的具体位置。
# -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 工具进行管理。警告信息中也提示了标准的操作命令：
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下的对应目录。
操作步骤：
备份并移除WSL2中原有的.ssh目录
mv ~/.ssh ~/.ssh_backup创建符号链接
ln -s /mnt/c/Users/我真棒/.ssh ~/.ssh修正目录和文件权限
这是非常关键的一步。由于Windows和Linux的文件权限系统不同，直接链接后可能导致权限过于开放，SSH会因此拒绝使用这些密钥。必须手动设置为SSH要求的严格权限。chmod 700 ~/.ssh chmod 600 ~/.ssh/id_rsa
完成配置后，WSL2中的所有SSH相关命令将默认使用Windows目录下的密钥和配置，实现了两个环境身份的统一，简化了后续操作。