可在Windows与WSL2间安全复用同一套ed25519 SSH密钥：Windows端生成密钥并严格限制权限，WSL2通过软链接引用该私钥，配置SSH客户端并修复权限校验，实现双向认证互通且不破坏各自权限模型。
想在Windows宿主机和WSL2之间复用同一套SSH密钥，避免每次连接GitHub、GitLab或远程服务器时重复生成、手动拷贝、权限出错甚至私钥暴露风险，就必须让双方能安全读取同一份密钥文件，且不破坏各自系统的权限模型。
确认Windows端已生成兼容密钥
打开PowerShell（普通用户即可），执行：
ssh-keygen -t ed25519 -C "your_email@example.com"
全程按回车使用默认路径 C:Users用户名.sshid_ed25519 和空密码短语。这一步必须做，因为WSL2无法直接读取Windows的OpenSSH默认密钥格式（如RSA 2048位）——ed25519是当前最稳妥的跨平台选择。
生成后检查 C:Users用户名.ssh 目录下是否存在 id_ed25519（私钥）和 id_ed25519.pub（公钥）两个文件。【私钥文件绝不能被Windows其他用户或应用读取】若发现该文件权限宽松（比如Everyone有读取权），立即右键→属性→安全→高级→禁用继承→删除所有非当前用户条目。
将Windows私钥软链接到WSL2的~/.ssh目录
在WSL2终端中执行：
wsl --shutdown
确保WSL2完全退出，否则后续挂载可能失败。
启动WSL2后，运行：
mkdir -p ~/.ssh && chmod 700 ~/.ssh
执行软链接命令：
ln -sf /mnt/c/Users/你的用户名/.ssh/id_ed25519 ~/.ssh/id_ed25519
注意：这里不能用cp硬复制，否则WSL2修改密钥权限会同步破坏Windows端安全性；也不能用Windows资源管理器拖拽，会导致换行符损坏和权限丢失。软链接保证源头唯一、实时同步、权限隔离。
验证链接是否生效：
ls -l ~/.ssh/id_ed25519
输出应显示指向 /mnt/c/... 的箭头，且文件大小为0字节。
配置WSL2端SSH客户端信任该密钥
第一步：创建配置文件
echo "IdentityFile ~/.ssh/id_ed25519" >> ~/.ssh/config
这行指令强制所有SSH连接优先使用该私钥，无需每次加 -i 参数。
第二步：修复WSL2对Windows挂载磁盘的权限识别问题
在WSL2中执行：
chmod 600 ~/.ssh/id_ed25519
虽然这是个软链接，但WSL2内核仍需“假装”它拥有标准私钥权限，否则ssh会拒绝加载。这不会改动Windows原文件权限，只是满足WSL2 SSH客户端的校验逻辑。
第三步：测试是否真正可用
ssh -T git@github.com
首次运行会提示“Are you sure you want to continue connecting?”，输入yes；成功则返回Hi xxx! You've successfully authenticated…
让Windows端也能读取WSL2生成的密钥（反向场景）
方法一：仅限临时调试，不推荐长期使用
在Windows PowerShell中，直接访问WSL2的虚拟文件系统：
Get-Content \wsl$Ubuntuhome你的用户名.sshid_ed25519
此路径由WSL2自动注册，无需额外配置，但不能写入，且每次重启WSL2后路径中的发行版名（如Ubuntu）需与wsl -l -v输出严格一致。
方法二：建立单向同步脚本（适合CI/CD或自动化场景）
在Windows上新建一个PowerShell脚本 sync-wsl-keys.ps1：
Copy-Item "\wsl$Ubuntuhome你的用户名.sshid_ed25519" "$env:USERPROFILE.sshid_ed25519_wsl" -Force
Set-ItemProperty "$env:USERPROFILE.sshid_ed25519_wsl" -Name Attributes -Value "Hidden"
运行该脚本后，可在Windows OpenSSH客户端中显式指定密钥：
ssh -i "$env:USERPROFILE.sshid_ed25519_wsl" user@host
