我按照这篇文章介绍的方法设置了 Windows 10 的 OpenSSH 服务器,以与 WSL2 的 bash 建立 ssh 连接:“如何从外部机器通过 SSH 轻松进入 Windows 10 上的 Bash 和 WSL2”,以及本文档:“OpenSSH 密钥管理”。
总之,我以管理员身份在 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 的密码从 PowerShell 通过 ssh 连接到本地主机上的 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 的结果与上面相同。
所以我的问题是:如何使用密钥对连接 Windows 10 上的 OpenSSH 服务器(其默认 shell 是 WSL2 的 bash)?我应该在哪里找到 authorized_keys?
答案1
我使用了类似的配置,在解决此类问题时,我遇到了一些问题。您的问题中已经提到了其中两个,所以您有一个好的开始。我在这里提到这些只是为了让其他人看到这个答案:
确保您使用的是 ECDSA 密钥而不是 RSA。Windows OpenSSH 服务器有一个错误(已在最新版本中修复,但未包含在 Windows 中),会导致 RSA 密钥失效。您在这里做得很好。
排除权限故障 - 确保
.ssh
目录(稍后讨论的位置)最多只能由 SYSTEM、用户和管理员组访问。其中的任何私钥文件也一样。
Match Group 管理员
最可能的原因如下... 如果您的 Windows 用户是管理员,那么默认的 Windows OpenSSH 配置可能“妨碍”了我们对 Unix/Linux 的合理期望 ;-)。请检查您的C:\ProgramData\ssh\sshd_config
。默认情况下,它可能在底部有以下几行:
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
我认为这是为了多用户系统的安全性。拥有一个用于维护授权密钥列表的中心位置可以更轻松地查看和更新该文件。搜索多个用户目录需要额外的努力。
因此你有两个选择:
由于您似乎使用的是单用户 Windows 10 系统,因此您只需注释掉这些行,重新启动 OpenSSH 服务器服务,然后您就可以使用您
authorized_keys
的%userprofile%\.ssh\authorized_keys
。如果你是做维护多用户系统,您可能只想使用将授权密钥放入的最佳实践
%programdata%\ssh\administrators_authorized_keys
。
DefaultShell 问题
最后,我看到当DefaultShell
注册表项中存在错误时,该项会被拒绝。您可能已经在输出中发现了这一点ssh -vvv
。它会返回类似以下内容的内容:
User not allowed because shell C:\\WINDOWS\\System32\\bash.exe does not exist
所以我猜这不是你的问题。话虽如此,我建议使用wsl.exe
而不是bash.exe
。后者并没有被完全弃用,但微软称它是启动 WSL 的“历史”命令,现在推荐功能更丰富(更不用说支持和测试)的wsl.exe
。
请注意,您还可以使用其他选项启动 WSL 会话 - 请参阅我的问题/答案这里有关详细信息,这是我最初遇到导致“类型 51”拒绝密钥的“不存在”错误的地方。
其他调试步骤
如果以上方法均无效,您也可以在调试模式下启动 OpenSSH 服务器。查看完整说明这里. psexec
如果您需要以 SYSTEM 身份运行它,那么它是可选的,但如果以普通用户身份运行它时遇到障碍,则建议您这样做。