1. 项目概述为什么要在Windows Server上折腾OpenSSH密钥登录如果你是一名运维工程师或者系统管理员最近接手了一台Windows Server每次登录都要输入那串又长又复杂的密码是不是觉得有点烦或者你正在构建一个自动化运维体系需要脚本能无密码、安全地登录到服务器执行任务密码登录的交互方式就成了拦路虎。这时候OpenSSH的密钥登录方式就该登场了。简单来说密钥登录就是用一对数学上关联的“钥匙”公钥和私钥来代替密码。你把公钥放在服务器上相当于给服务器装了一把特殊的锁你用自己的私钥存放在本地客户端去开这把锁。这种方式比密码安全得多因为它几乎无法被暴力破解同时也免去了每次手动输入密码的麻烦是实现自动化运维的基石。我最近就在一台全新的Windows Server 2022上完整走了一遍配置流程过程比在Linux上要“精彩”不少尤其是在权限问题上踩的坑一个接一个。网上很多教程要么步骤不全要么对Windows特有的权限问题一笔带过导致新手照着做十有八九会卡住。这篇文章我就把我从零开始配置OpenSSH密钥登录的完整流程以及那些让我头疼的权限坑毫无保留地记录下来。无论你用的是Server 2016、2019还是2022这套流程和避坑指南都适用。2. 核心思路与方案选型Windows OpenSSH的“特殊性”在Linux世界配置SSH密钥登录几乎是每个运维的肌肉记忆ssh-keygen,ssh-copy-id, 改改~/.ssh权限一气呵成。但到了Windows Server事情就变得微妙起来。首先我们需要理解Windows OpenSSH的两个核心“特殊性”。2.1 内置OpenSSH客户端与服务器的区别从Windows Server 2019和Windows 10 1809开始微软在系统中内置了OpenSSH的客户端。这意味着你可以在PowerShell或CMD里直接使用ssh,scp,ssh-keygen等命令无需额外安装。这很方便但请注意这只是客户端。我们想要实现密钥登录需要在服务器端安装并运行OpenSSH的服务器组件。这个服务器组件在较新的Windows Server版本如2022中可以通过“添加角色和功能”向导来安装它是一个Windows服务名为sshd。而在稍旧的版本如2016中可能需要手动下载微软官方发布的OpenSSH for Windows移植版进行安装。这是第一个容易混淆的点你本地有ssh命令不代表你的服务器已经开启了SSH服务。2.2 Windows权限模型与Linux的差异这是踩坑的重灾区。Linux的权限基于用户、组和其他人的读r、写w、执行x权限位简单直接。Windows的权限体系要复杂得多它是基于访问控制列表ACL的包含了大量细粒度的权限项如“完全控制”、“修改”、“读取和执行”、“读取”、“写入”等并且可以继承。当我们把Linux那套chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys的经验直接搬到Windows时往往会因为ACL设置不正确而导致SSH服务器拒绝我们的密钥。Windows的sshd服务在读取密钥文件时会对当前用户的家目录C:\Users\用户名\、.ssh文件夹以及authorized_keys文件进行严格的ACL检查。如果权限过于宽松比如Everyone有读取权限或者继承关系混乱即使文件内容正确认证也会失败并通常在系统日志中留下模糊的错误信息。理解并正确配置ACL是本次任务成功的关键。3. 完整配置流程与实操要点下面我将以一台纯净的Windows Server 2022为例演示从零开始的完整配置流程。整个过程分为服务器端配置和客户端配置两部分。3.1 服务器端安装与配置OpenSSH服务器首先我们需要在目标Windows Server上安装并启用SSH服务。步骤1安装OpenSSH服务器功能以管理员身份打开PowerShell。检查是否已安装OpenSSH相关功能Get-WindowsCapability -Online | Where-Object Name -like OpenSSH*如果返回结果中State为NotPresent则表示未安装。安装OpenSSH服务器组件Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0安装过程可能需要几分钟并可能要求重启。在Server 2022上我实测无需重启即可进行下一步。步骤2启动并配置SSH服务启动SSH服务sshd并设置为开机自启Start-Service sshd Set-Service -Name sshd -StartupType Automatic可选但推荐修改SSH服务器配置。配置文件位于C:\ProgramData\ssh\sshd_config。用记事本需管理员权限或notepad命令打开它。确保启用密钥认证找到PubkeyAuthentication一行确保其设置为yes默认通常是。禁用密码登录增强安全找到PasswordAuthentication将其改为no。注意在确认密钥登录成功前先不要改这项指定授权密钥文件位置找到AuthorizedKeysFile默认是.ssh/authorized_keys .ssh/authorized_keys2。这个路径是相对于用户家目录的在Windows上就是C:\Users\用户名\.ssh\authorized_keys。保持默认即可。每次修改sshd_config后需要重启sshd服务使配置生效Restart-Service sshd配置Windows防火墙允许SSH端口22入站连接New-NetFirewallRule -Name OpenSSH-Server-In-TCP -DisplayName OpenSSH Server (sshd) -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22或者你也可以在“高级安全Windows Defender防火墙”图形界面中手动添加规则。注意C:\ProgramData\ssh目录下的sshd_config是全局配置文件。而每个用户的.ssh目录和authorized_keys文件我们稍后再创建和配置。3.2 客户端生成并准备密钥对接下来我们在用来连接服务器的客户端机器上操作。这台机器可以是另一台Windows使用内置的OpenSSH客户端、Linux或macOS。步骤1生成密钥对在客户端的PowerShellWindows或终端Linux/macOS中执行ssh-keygen -t rsa -b 4096 -C your_emailexample.com-t rsa: 指定密钥类型为RSA。Ed25519更优但为了最大兼容性这里先用RSA。-b 4096: 指定密钥长度为4096位安全性更高。-C: 添加一个注释通常用邮箱便于标识密钥所有者。执行命令后它会询问你密钥文件的保存路径默认在~/.ssh/id_rsa和私钥密码passphrase。私钥密码可以为空直接回车但设置一个密码能提供额外一层安全保护即使私钥文件泄露没有密码也无法使用。完成后你会在~/.ssh/目录下得到两个文件id_rsa:私钥文件必须严格保密相当于你的家门钥匙。id_rsa.pub:公钥文件可以公开分发相当于锁芯。步骤2将公钥上传至服务器这是将“锁芯”安装到服务器上的步骤。假设服务器IP是192.168.1.100用户名是adminuser。方法A使用ssh-copy-idLinux/macOS客户端或Windows上安装了相应工具ssh-copy-id -i ~/.ssh/id_rsa.pub adminuser192.168.1.100这个命令会自动将你的公钥追加到服务器对应用户家目录的~/.ssh/authorized_keys文件中。但在Windows Server上由于权限问题这个方法经常失败。方法B手动复制最可靠的方法在客户端打印出公钥内容cat ~/.ssh/id_rsa.pub复制输出的全部文本它是一行以ssh-rsa AAAAB3NzaC1yc2E...开头的内容。登录到Windows Server此时先用密码登录。在服务器上打开PowerShell为当前用户创建.ssh目录和authorized_keys文件# 切换到用户家目录 cd ~ # 创建.ssh目录如果不存在 New-Item -ItemType Directory -Force -Path .ssh # 将复制的公钥内容追加到authorized_keys文件 Add-Content -Path .ssh\authorized_keys -Value 这里粘贴你复制的整行公钥内容关键点来了现在文件内容有了但权限大概率是错的。直接尝试密钥登录很可能会收到“Permission denied (publickey)”的错误。4. 权限踩坑实录与终极解决方案到了这里几乎所有教程都会说“好了现在可以密钥登录了”。但当你兴冲冲地执行ssh adminuser192.168.1.100时等待你的很可能是一盆冷水。下面就是我遇到的坑以及如何填平它们。4.1 错误现象与初步排查当你密钥登录失败时首先在客户端使用-vverbose参数查看详细输出ssh -v adminuser192.168.1.100在输出中你可能会看到服务器已经接受了你的公钥Offering public key但紧接着是Authentication refused: bad ownership or modes for file之类的错误然后回退到密码认证如果你没禁用的话。这说明sshd服务认为你的.ssh目录或authorized_keys文件的权限不安全。我们需要到服务器上检查并修正这些权限。4.2 权限修复使用icacls命令设置正确ACLWindows上没有chmod我们需要使用icacls命令来管理ACL。目标是为当前用户的家目录、.ssh文件夹和authorized_keys文件设置严格的权限移除所有其他用户和组的访问权限并禁止继承。请严格按照以下顺序和命令在服务器的PowerShell中执行假设用户名是adminuser步骤1修复用户家目录权限仅必要时通常家目录权限是继承来的可能没问题。但为了保险可以检查并确保只有管理员Administrators和该用户自己有完全控制权。# 查看当前家目录权限 icacls $env:USERPROFILE # 如果发现有不必要的用户如Users组有写入权限可以重置。但操作需谨慎建议先备份权限。步骤2修复.ssh目录权限关键这是最容易出错的一步。我们需要移除所有继承的权限。授予SYSTEM和当前用户完全控制权限。移除其他所有用户和组。# 进入.ssh目录 cd ~\.ssh # 1. 禁用继承并删除所有现有权限 icacls . /inheritance:r # 2. 授予SYSTEM完全控制权限 icacls . /grant SYSTEM:F # 3. 授予当前用户完全控制权限。$env:USERNAME是当前用户名变量。 icacls . /grant ${env:USERNAME}:F # 4. 验证权限 icacls .执行后icacls .的输出应该只显示两条记录NT AUTHORITY\SYSTEM和你的计算机名\adminuser都具有(F)完全控制权限。绝对不能出现Everyone,BUILTIN\Users等条目。步骤3修复authorized_keys文件权限同样关键对文件的操作类似但权限可以稍严格一些用户只需要“读取”权限即可因为sshd进程需要读取它。# 确保在.ssh目录下 # 1. 禁用继承并删除所有现有权限 icacls authorized_keys /inheritance:r # 2. 授予SYSTEM完全控制权限F icacls authorized_keys /grant SYSTEM:F # 3. 授予当前用户读取权限R。注意这里是R不是F。 icacls authorized_keys /grant ${env:USERNAME}:R # 4. 验证权限 icacls authorized_keys正确的输出应该显示SYSTEM有(F)你的用户有(R)。实操心得我最初在这里踩了大坑。我像在Linux一样试图给文件设置“只有所有者可读写”即icacls file /grant user:F。但忽略了Windows上sshd服务默认是以SYSTEM或一个特定的sshd账户身份运行的。如果SYSTEM账户没有权限读取这个文件认证就会失败。所以必须给SYSTEM账户完全控制F权限这是与Linux操作逻辑最大的不同。4.3 验证与最终测试完成权限设置后务必重启sshd服务以确保服务进程重新加载配置并感知到新的文件权限。Restart-Service sshd现在回到你的客户端再次尝试连接ssh adminuser192.168.1.100如果一切配置正确你应该不需要输入密码就能直接登录到服务器了。如果仍然失败请检查服务器的事件查看器。打开“事件查看器” - “Windows 日志” - “应用程序”筛选来源为“OpenSSH”的日志。里面通常会有更详细的错误信息例如“Authentication refused: bad ownership or modes for directory C:\Users\adminuser.ssh”这能帮你精准定位是哪个路径的权限还有问题。5. 进阶配置与安全加固密钥登录成功后我们可以进行一些进阶操作来提升便利性和安全性。5.1 使用SSH Config文件管理连接在客户端~/.ssh/config文件没有则创建中可以为服务器创建别名并指定使用的私钥。# ~/.ssh/config 文件内容 Host myserver HostName 192.168.1.100 User adminuser IdentityFile ~/.ssh/id_rsa Port 22保存后在客户端直接使用ssh myserver即可连接无需指定IP、用户名和密钥路径。5.2 彻底禁用密码登录确认密钥登录稳定可靠后为了安全应该禁用密码登录。编辑服务器上的C:\ProgramData\ssh\sshd_config文件找到并修改PasswordAuthentication no然后重启sshd服务。5.3 使用更安全的Ed25519密钥RSA 4096已经很安全但Ed25519在安全性和性能上更优。生成Ed25519密钥对ssh-keygen -t ed25519 -C your_emailexample.com后续的传输和配置流程与RSA密钥完全相同。5.4 服务账户与权限的深入理解为什么一定要给SYSTEM权限这是因为Windows服务如sshd在运行时其安全上下文Security Context通常是LOCAL SYSTEM账户或一个你指定的服务账户。这个账户需要能够遍历用户的家目录、读取.ssh文件夹和authorized_keys文件。通过ACL授予SYSTEM权限就是允许服务账户进行这些操作。你可以通过服务管理器services.msc查看OpenSSH SSH Server服务的“登录”选项卡来了解它具体以什么账户运行。6. 常见问题排查速查表即使按照上述步骤操作你可能还是会遇到一些问题。下表汇总了常见错误和解决方法问题现象可能原因排查与解决步骤Permission denied (publickey)1. 公钥未正确放入authorized_keys。2..ssh或authorized_keys文件权限错误。3.sshd_config中PubkeyAuthentication未设置为yes。1. 检查authorized_keys文件内容确保公钥是完整一行。2.重点使用icacls命令严格按照第4部分检查并重置.ssh目录和authorized_keys文件的ACL权限。3. 检查C:\ProgramData\ssh\sshd_config文件确保PubkeyAuthentication yes。连接超时或Connection refused1. SSH服务未启动。2. 防火墙未放行22端口。3. 服务器IP或端口错误。1. 在服务器运行Get-Service sshd查看状态确保为Running。2. 检查防火墙规则确保有允许TCP 22端口入站的规则。3. 使用netstat -an仍提示输入密码密钥已配置1. 客户端未使用正确的私钥。2.authorized_keys文件权限过宽如Everyone可读。3. 家目录权限过宽。1. 使用ssh -i /path/to/private_key userhost指定私钥或在~/.ssh/config中配置IdentityFile。2. 再次检查authorized_keys文件的ACL确保只有SYSTEM和相应用户有权限无其他条目。3. 检查用户家目录的ACL不应有过于宽松的权限。事件查看器错误bad ownership or modes目标文件或目录的ACL不符合OpenSSH的安全要求。这是最明确的指示。逐级检查家目录、.ssh目录、authorized_keys文件的ACL。使用icacls命令确保继承已禁用且权限列表简洁只有SYSTEM和用户本身。登录成功后立即断开可能用户Shell配置有问题或者sshd_config中配置了强制命令。检查服务器上对应用户的~/.ssh/authorized_keys文件看公钥前面是否被添加了command等强制选项。检查用户环境变量。最后再分享一个小技巧在调试权限问题时一个非常有效的方法是“对比法”。找一台配置成功的Windows Server或者在一开始权限还没乱的时候使用icacls C:\Users\youruser\.ssh和icacls C:\Users\youruser\.ssh\authorized_keys命令输出正确的权限列表。然后在出问题的机器上按照正确的输出逐条修复。这比单纯记忆命令更不容易出错。权限问题虽然棘手但一旦理解了Windows ACL的工作原理和OpenSSH的安全要求解决起来就有章可循了。
1. 项目概述为什么要在Windows Server上折腾OpenSSH密钥登录如果你是一名运维工程师或者系统管理员最近接手了一台Windows Server每次登录都要输入那串又长又复杂的密码是不是觉得有点烦或者你正在构建一个自动化运维体系需要脚本能无密码、安全地登录到服务器执行任务密码登录的交互方式就成了拦路虎。这时候OpenSSH的密钥登录方式就该登场了。简单来说密钥登录就是用一对数学上关联的“钥匙”公钥和私钥来代替密码。你把公钥放在服务器上相当于给服务器装了一把特殊的锁你用自己的私钥存放在本地客户端去开这把锁。这种方式比密码安全得多因为它几乎无法被暴力破解同时也免去了每次手动输入密码的麻烦是实现自动化运维的基石。我最近就在一台全新的Windows Server 2022上完整走了一遍配置流程过程比在Linux上要“精彩”不少尤其是在权限问题上踩的坑一个接一个。网上很多教程要么步骤不全要么对Windows特有的权限问题一笔带过导致新手照着做十有八九会卡住。这篇文章我就把我从零开始配置OpenSSH密钥登录的完整流程以及那些让我头疼的权限坑毫无保留地记录下来。无论你用的是Server 2016、2019还是2022这套流程和避坑指南都适用。2. 核心思路与方案选型Windows OpenSSH的“特殊性”在Linux世界配置SSH密钥登录几乎是每个运维的肌肉记忆ssh-keygen,ssh-copy-id, 改改~/.ssh权限一气呵成。但到了Windows Server事情就变得微妙起来。首先我们需要理解Windows OpenSSH的两个核心“特殊性”。2.1 内置OpenSSH客户端与服务器的区别从Windows Server 2019和Windows 10 1809开始微软在系统中内置了OpenSSH的客户端。这意味着你可以在PowerShell或CMD里直接使用ssh,scp,ssh-keygen等命令无需额外安装。这很方便但请注意这只是客户端。我们想要实现密钥登录需要在服务器端安装并运行OpenSSH的服务器组件。这个服务器组件在较新的Windows Server版本如2022中可以通过“添加角色和功能”向导来安装它是一个Windows服务名为sshd。而在稍旧的版本如2016中可能需要手动下载微软官方发布的OpenSSH for Windows移植版进行安装。这是第一个容易混淆的点你本地有ssh命令不代表你的服务器已经开启了SSH服务。2.2 Windows权限模型与Linux的差异这是踩坑的重灾区。Linux的权限基于用户、组和其他人的读r、写w、执行x权限位简单直接。Windows的权限体系要复杂得多它是基于访问控制列表ACL的包含了大量细粒度的权限项如“完全控制”、“修改”、“读取和执行”、“读取”、“写入”等并且可以继承。当我们把Linux那套chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys的经验直接搬到Windows时往往会因为ACL设置不正确而导致SSH服务器拒绝我们的密钥。Windows的sshd服务在读取密钥文件时会对当前用户的家目录C:\Users\用户名\、.ssh文件夹以及authorized_keys文件进行严格的ACL检查。如果权限过于宽松比如Everyone有读取权限或者继承关系混乱即使文件内容正确认证也会失败并通常在系统日志中留下模糊的错误信息。理解并正确配置ACL是本次任务成功的关键。3. 完整配置流程与实操要点下面我将以一台纯净的Windows Server 2022为例演示从零开始的完整配置流程。整个过程分为服务器端配置和客户端配置两部分。3.1 服务器端安装与配置OpenSSH服务器首先我们需要在目标Windows Server上安装并启用SSH服务。步骤1安装OpenSSH服务器功能以管理员身份打开PowerShell。检查是否已安装OpenSSH相关功能Get-WindowsCapability -Online | Where-Object Name -like OpenSSH*如果返回结果中State为NotPresent则表示未安装。安装OpenSSH服务器组件Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0安装过程可能需要几分钟并可能要求重启。在Server 2022上我实测无需重启即可进行下一步。步骤2启动并配置SSH服务启动SSH服务sshd并设置为开机自启Start-Service sshd Set-Service -Name sshd -StartupType Automatic可选但推荐修改SSH服务器配置。配置文件位于C:\ProgramData\ssh\sshd_config。用记事本需管理员权限或notepad命令打开它。确保启用密钥认证找到PubkeyAuthentication一行确保其设置为yes默认通常是。禁用密码登录增强安全找到PasswordAuthentication将其改为no。注意在确认密钥登录成功前先不要改这项指定授权密钥文件位置找到AuthorizedKeysFile默认是.ssh/authorized_keys .ssh/authorized_keys2。这个路径是相对于用户家目录的在Windows上就是C:\Users\用户名\.ssh\authorized_keys。保持默认即可。每次修改sshd_config后需要重启sshd服务使配置生效Restart-Service sshd配置Windows防火墙允许SSH端口22入站连接New-NetFirewallRule -Name OpenSSH-Server-In-TCP -DisplayName OpenSSH Server (sshd) -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22或者你也可以在“高级安全Windows Defender防火墙”图形界面中手动添加规则。注意C:\ProgramData\ssh目录下的sshd_config是全局配置文件。而每个用户的.ssh目录和authorized_keys文件我们稍后再创建和配置。3.2 客户端生成并准备密钥对接下来我们在用来连接服务器的客户端机器上操作。这台机器可以是另一台Windows使用内置的OpenSSH客户端、Linux或macOS。步骤1生成密钥对在客户端的PowerShellWindows或终端Linux/macOS中执行ssh-keygen -t rsa -b 4096 -C your_emailexample.com-t rsa: 指定密钥类型为RSA。Ed25519更优但为了最大兼容性这里先用RSA。-b 4096: 指定密钥长度为4096位安全性更高。-C: 添加一个注释通常用邮箱便于标识密钥所有者。执行命令后它会询问你密钥文件的保存路径默认在~/.ssh/id_rsa和私钥密码passphrase。私钥密码可以为空直接回车但设置一个密码能提供额外一层安全保护即使私钥文件泄露没有密码也无法使用。完成后你会在~/.ssh/目录下得到两个文件id_rsa:私钥文件必须严格保密相当于你的家门钥匙。id_rsa.pub:公钥文件可以公开分发相当于锁芯。步骤2将公钥上传至服务器这是将“锁芯”安装到服务器上的步骤。假设服务器IP是192.168.1.100用户名是adminuser。方法A使用ssh-copy-idLinux/macOS客户端或Windows上安装了相应工具ssh-copy-id -i ~/.ssh/id_rsa.pub adminuser192.168.1.100这个命令会自动将你的公钥追加到服务器对应用户家目录的~/.ssh/authorized_keys文件中。但在Windows Server上由于权限问题这个方法经常失败。方法B手动复制最可靠的方法在客户端打印出公钥内容cat ~/.ssh/id_rsa.pub复制输出的全部文本它是一行以ssh-rsa AAAAB3NzaC1yc2E...开头的内容。登录到Windows Server此时先用密码登录。在服务器上打开PowerShell为当前用户创建.ssh目录和authorized_keys文件# 切换到用户家目录 cd ~ # 创建.ssh目录如果不存在 New-Item -ItemType Directory -Force -Path .ssh # 将复制的公钥内容追加到authorized_keys文件 Add-Content -Path .ssh\authorized_keys -Value 这里粘贴你复制的整行公钥内容关键点来了现在文件内容有了但权限大概率是错的。直接尝试密钥登录很可能会收到“Permission denied (publickey)”的错误。4. 权限踩坑实录与终极解决方案到了这里几乎所有教程都会说“好了现在可以密钥登录了”。但当你兴冲冲地执行ssh adminuser192.168.1.100时等待你的很可能是一盆冷水。下面就是我遇到的坑以及如何填平它们。4.1 错误现象与初步排查当你密钥登录失败时首先在客户端使用-vverbose参数查看详细输出ssh -v adminuser192.168.1.100在输出中你可能会看到服务器已经接受了你的公钥Offering public key但紧接着是Authentication refused: bad ownership or modes for file之类的错误然后回退到密码认证如果你没禁用的话。这说明sshd服务认为你的.ssh目录或authorized_keys文件的权限不安全。我们需要到服务器上检查并修正这些权限。4.2 权限修复使用icacls命令设置正确ACLWindows上没有chmod我们需要使用icacls命令来管理ACL。目标是为当前用户的家目录、.ssh文件夹和authorized_keys文件设置严格的权限移除所有其他用户和组的访问权限并禁止继承。请严格按照以下顺序和命令在服务器的PowerShell中执行假设用户名是adminuser步骤1修复用户家目录权限仅必要时通常家目录权限是继承来的可能没问题。但为了保险可以检查并确保只有管理员Administrators和该用户自己有完全控制权。# 查看当前家目录权限 icacls $env:USERPROFILE # 如果发现有不必要的用户如Users组有写入权限可以重置。但操作需谨慎建议先备份权限。步骤2修复.ssh目录权限关键这是最容易出错的一步。我们需要移除所有继承的权限。授予SYSTEM和当前用户完全控制权限。移除其他所有用户和组。# 进入.ssh目录 cd ~\.ssh # 1. 禁用继承并删除所有现有权限 icacls . /inheritance:r # 2. 授予SYSTEM完全控制权限 icacls . /grant SYSTEM:F # 3. 授予当前用户完全控制权限。$env:USERNAME是当前用户名变量。 icacls . /grant ${env:USERNAME}:F # 4. 验证权限 icacls .执行后icacls .的输出应该只显示两条记录NT AUTHORITY\SYSTEM和你的计算机名\adminuser都具有(F)完全控制权限。绝对不能出现Everyone,BUILTIN\Users等条目。步骤3修复authorized_keys文件权限同样关键对文件的操作类似但权限可以稍严格一些用户只需要“读取”权限即可因为sshd进程需要读取它。# 确保在.ssh目录下 # 1. 禁用继承并删除所有现有权限 icacls authorized_keys /inheritance:r # 2. 授予SYSTEM完全控制权限F icacls authorized_keys /grant SYSTEM:F # 3. 授予当前用户读取权限R。注意这里是R不是F。 icacls authorized_keys /grant ${env:USERNAME}:R # 4. 验证权限 icacls authorized_keys正确的输出应该显示SYSTEM有(F)你的用户有(R)。实操心得我最初在这里踩了大坑。我像在Linux一样试图给文件设置“只有所有者可读写”即icacls file /grant user:F。但忽略了Windows上sshd服务默认是以SYSTEM或一个特定的sshd账户身份运行的。如果SYSTEM账户没有权限读取这个文件认证就会失败。所以必须给SYSTEM账户完全控制F权限这是与Linux操作逻辑最大的不同。4.3 验证与最终测试完成权限设置后务必重启sshd服务以确保服务进程重新加载配置并感知到新的文件权限。Restart-Service sshd现在回到你的客户端再次尝试连接ssh adminuser192.168.1.100如果一切配置正确你应该不需要输入密码就能直接登录到服务器了。如果仍然失败请检查服务器的事件查看器。打开“事件查看器” - “Windows 日志” - “应用程序”筛选来源为“OpenSSH”的日志。里面通常会有更详细的错误信息例如“Authentication refused: bad ownership or modes for directory C:\Users\adminuser.ssh”这能帮你精准定位是哪个路径的权限还有问题。5. 进阶配置与安全加固密钥登录成功后我们可以进行一些进阶操作来提升便利性和安全性。5.1 使用SSH Config文件管理连接在客户端~/.ssh/config文件没有则创建中可以为服务器创建别名并指定使用的私钥。# ~/.ssh/config 文件内容 Host myserver HostName 192.168.1.100 User adminuser IdentityFile ~/.ssh/id_rsa Port 22保存后在客户端直接使用ssh myserver即可连接无需指定IP、用户名和密钥路径。5.2 彻底禁用密码登录确认密钥登录稳定可靠后为了安全应该禁用密码登录。编辑服务器上的C:\ProgramData\ssh\sshd_config文件找到并修改PasswordAuthentication no然后重启sshd服务。5.3 使用更安全的Ed25519密钥RSA 4096已经很安全但Ed25519在安全性和性能上更优。生成Ed25519密钥对ssh-keygen -t ed25519 -C your_emailexample.com后续的传输和配置流程与RSA密钥完全相同。5.4 服务账户与权限的深入理解为什么一定要给SYSTEM权限这是因为Windows服务如sshd在运行时其安全上下文Security Context通常是LOCAL SYSTEM账户或一个你指定的服务账户。这个账户需要能够遍历用户的家目录、读取.ssh文件夹和authorized_keys文件。通过ACL授予SYSTEM权限就是允许服务账户进行这些操作。你可以通过服务管理器services.msc查看OpenSSH SSH Server服务的“登录”选项卡来了解它具体以什么账户运行。6. 常见问题排查速查表即使按照上述步骤操作你可能还是会遇到一些问题。下表汇总了常见错误和解决方法问题现象可能原因排查与解决步骤Permission denied (publickey)1. 公钥未正确放入authorized_keys。2..ssh或authorized_keys文件权限错误。3.sshd_config中PubkeyAuthentication未设置为yes。1. 检查authorized_keys文件内容确保公钥是完整一行。2.重点使用icacls命令严格按照第4部分检查并重置.ssh目录和authorized_keys文件的ACL权限。3. 检查C:\ProgramData\ssh\sshd_config文件确保PubkeyAuthentication yes。连接超时或Connection refused1. SSH服务未启动。2. 防火墙未放行22端口。3. 服务器IP或端口错误。1. 在服务器运行Get-Service sshd查看状态确保为Running。2. 检查防火墙规则确保有允许TCP 22端口入站的规则。3. 使用netstat -an仍提示输入密码密钥已配置1. 客户端未使用正确的私钥。2.authorized_keys文件权限过宽如Everyone可读。3. 家目录权限过宽。1. 使用ssh -i /path/to/private_key userhost指定私钥或在~/.ssh/config中配置IdentityFile。2. 再次检查authorized_keys文件的ACL确保只有SYSTEM和相应用户有权限无其他条目。3. 检查用户家目录的ACL不应有过于宽松的权限。事件查看器错误bad ownership or modes目标文件或目录的ACL不符合OpenSSH的安全要求。这是最明确的指示。逐级检查家目录、.ssh目录、authorized_keys文件的ACL。使用icacls命令确保继承已禁用且权限列表简洁只有SYSTEM和用户本身。登录成功后立即断开可能用户Shell配置有问题或者sshd_config中配置了强制命令。检查服务器上对应用户的~/.ssh/authorized_keys文件看公钥前面是否被添加了command等强制选项。检查用户环境变量。最后再分享一个小技巧在调试权限问题时一个非常有效的方法是“对比法”。找一台配置成功的Windows Server或者在一开始权限还没乱的时候使用icacls C:\Users\youruser\.ssh和icacls C:\Users\youruser\.ssh\authorized_keys命令输出正确的权限列表。然后在出问题的机器上按照正确的输出逐条修复。这比单纯记忆命令更不容易出错。权限问题虽然棘手但一旦理解了Windows ACL的工作原理和OpenSSH的安全要求解决起来就有章可循了。
)
