通过证书认证的WinRM本地访问WSL2文件系统的可行性及问题排查

首先可以明确：你遇到的问题确实和证书认证下WinRM的凭据委派限制有关，哪怕是本地访问的场景也逃不开这个约束。下面我会拆解原因，再给几个不用切换到CredSSP的解决方案：

为什么交互式PowerShell能用，但WinRM会话不行？ #

当你在桌面打开PowerShell时，是用当前登录用户的上下文直接访问WSL的虚拟共享（\\wsl.localhost\...），系统会自动用你当前的用户权限去验证访问。但WinRM用证书认证建立会话时，这个会话运行在一个独立的服务级上下文里——它不会自动继承你交互式登录的凭据，也没有像CredSSP那样的机制来传递凭据给后续的UNC访问操作，哪怕目标是本地的WSL共享，也会被系统判定为“无权限访问”。

可行的解决方案 #

1. 直接在WSL上下文执行文件操作（最推荐） #

既然你的Ansible playbook本身就在WSL里运行，完全可以绕开WinRM，直接用Ansible的普通shell/command模块在WSL环境里操作文件。比如：

- name: 列出WSL目录下的文件
  shell: ls /home/foo/bar
  delegate_to: localhost

这种方式不需要走WinRM，直接利用WSL自身的环境，完全避免了UNC路径的权限问题，操作效率也更高。

2. 调整WinRM服务的身份模拟配置 #

如果一定要通过WinRM访问WSL共享，可以尝试调整WinRM服务端的身份模拟级别，让证书认证的会话能模拟用户身份访问本地资源：

1. 以管理员身份打开PowerShell，执行以下命令设置WinRM的身份模拟级别：

   Set-Item WSMan:\localhost\Service\ImpersonationLevel -Value Impersonate
   

2. 确保证书认证的用户拥有访问WSL文件系统的权限：WSL的文件系统权限和Linux侧一致，你可以先在WSL里给对应用户（比如Windows侧的证书用户对应的Linux用户）设置好/home/foo/bar目录的读写权限。
3. 重启WinRM服务生效：

   Restart-Service WinRM
   

不过要注意：证书认证下WinRM的委派能力有限，这个方法只在本地访问场景下大概率有效，跨机器的话还是会有问题，但你的场景正好是localhost，值得一试。

3. 在WinRM会话中临时映射网络驱动器 #

你可以在win_shell任务里先把WSL共享映射成一个本地驱动器，再通过驱动器路径访问文件，这样能规避直接访问UNC路径的权限问题：

- name: 映射WSL共享并列出文件
  win_shell: |
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\wsl.localhost\Ubuntu\home\foo" -Scope Global
    Get-ChildItem Z:\bar

这个映射只在当前WinRM会话中有效，每次会话都需要重新创建，但能解决临时访问的需求。

额外注意事项 #

• 确保WSL实例处于运行状态：如果Ubuntu实例没启动，\\wsl.localhost\Ubuntu路径肯定无法访问，可以在playbook里先加一个任务启动WSL：shell: wsl -d Ubuntu --exec true
• 证书对应的Windows用户需要是本地管理员或者拥有“登录作为服务”的权限：WinRM会话的运行依赖这个权限，否则可能出现上下文权限不足的问题。

备注：内容来源于stack exchange，提问作者blami