nek*_*uuu 2 ssh windows-10 windows-subsystem-for-linux wsl2
我设置了 Windows 10 的 OpenSSH 服务器，通过本文中描述的方法建立到 WSL2 bash 的 ssh 连接：“THE EASY WAY how to SSH into Bash and WSL2 on Windows 10 from an external machine”，以及本文档：“OpenSSH key管理”。
总之，我以管理员身份在 PowerShell 上运行以下命令：
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\System32\bash.exe" -PropertyType String -Force
之后，我可以ssh <my Windows username>@localhost使用 Windows 密码通过 ssh 从 PowerShell 连接到本地主机上的 WSL2 bash。
接下来，我想不使用密码而是使用密钥对进行连接。因此，我在 PowerShell 上创建了一个密钥对并将其定位为C:\Users\<my Windows username>\.ssh\authorized_keys.
cd C:\Users\<my Windows username>\.ssh
ssh-keygen -t ed25519 -f id_ed25519
copy id_ed25519.pub authorized_keys
但这不允许我使用密钥对连接本地主机。在提供私钥的公钥后，命令立即ssh -vvv -i C:\Users\<my Windows username>\.ssh\id_ed25519 <my Windows username>@localhost返回带有日志行的权限错误。debug3: receive packet: type 51
作为另一次尝试，我在WSL2的主目录中找到authorized_keys/home/<my WSL2 username>/.ssh并运行chmod 600，但在PowerShell上ssh的结果与上面相同。
所以我的问题是：如何使用密钥对在默认 shell 是 WSL2 的 bash 的 Windows 10 上连接 OpenSSH 服务器？我应该在哪里找到authorized_keys？
我使用类似的配置，在解决此类问题时遇到了一些问题。您的问题中已经提到了其中两个，所以您有了一个良好的开端。我只是在这里为其他看到这个答案的人提到这些：
确保您使用的是 ECDSA 密钥而不是 RSA。Windows OpenSSH 服务器有一个错误（在最新版本中已修复，但未包含在 Windows 中），导致 RSA 密钥失败。你在这里很好。
权限故障排除 - 确保该.ssh目录（稍后讨论的位置）最多只能由 SYSTEM、用户和管理员组访问。对于其中的任何私钥文件都是如此。
最可能的原因是……如果您的 Windows 用户是管理员，那么默认的 Windows OpenSSH 配置可能会“妨碍”我们合理的 Unix/Linux 期望;-)。检查你的C:\ProgramData\ssh\sshd_config。默认情况下，它的底部可能有以下几行：
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
我假设这是为了多用户系统的安全性。拥有一个用于维护授权密钥列表的中央位置可以更轻松地查看和更新该文件。必须搜索多个用户目录将需要额外的努力。
所以你有两个选择：
由于您似乎使用的是单用户 Windows 10 系统，因此您只需注释掉这些行，重新启动 OpenSSH Server 服务，然后您应该就可以使用您的authorized_keysin %userprofile%\.ssh\authorized_keys.
如果您确实维护多用户系统，您可能只想使用将授权密钥放入%programdata%\ssh\administrators_authorized_keys.
最后，我发现当注册表项出现错误时，该项会被拒绝DefaultShell。您可能已经在ssh -vvv输出中发现了这一点。它会返回类似以下内容：
User not allowed because shell C:\\WINDOWS\\System32\\bash.exe does not exist
所以我猜这不是你的问题。也就是说，我建议使用wsl.exe而不是bash.exe. 后者并未完全被弃用，但 Microsoft 称其为启动 WSL 的“历史”命令，并且现在推荐功能更丰富（更不用说支持和测试）的wsl.exe.
请注意，您还可以使用其他选项启动 WSL 会话 - 有关详细信息，请参阅此处我的问题/答案，这是我最初遇到的“不存在”错误，该错误导致“类型 51”拒绝密钥。
如果以上方法都不起作用，您还可以在调试模式下启动 OpenSSH 服务器。请参阅此处的完整说明。 psexec如果您需要以系统身份运行它，则在某种程度上是可选的，但如果您以普通用户身份运行它遇到困难，则建议您这样做。