Can't connect to non-admin Windows account (Get-CimInstance PermissionDenied)

[ericblade]

• VSCode Version: 1.43.2
• Local OS Version: Windows 18363.720
• Remote OS Version: Windows 18363.720
• Remote Extension/Connection Type: SSH

Steps to Reproduce:

1. Attempt to login to remote Windows server

Does this issue occur when you try this locally?: This is a connection specific issue
Does this issue occur when you try this locally and all extensions are disabled?: This is a connection specific issue

Attempting to use VSC remote with a remote SSH server on Windows. I've installed the Windows 10 OpenSSH server using Add/Remove features. I can connect to it using my regular Linux host, my WSL host, and native windows ssh.

When I attempt to connect to this host with VSCode, first it asks me what OS i'm using, I enter Windows.

Then it asks for my password. It chugs along for a little while, with the following log output, and then stops with a modal "Could not establish connection to 'arcade.lan'."

Seems unrelated to #2198, I think?

[19:26:15.859] Log Level: 2
[19:26:15.861] remote-ssh@0.51.0
[19:26:15.861] win32 x64
[19:26:15.863] SSH Resolver called for "ssh-remote+arcade.lan", attempt 1
[19:26:15.863] SSH Resolver called for host: arcade.lan
[19:26:15.863] Setting up SSH remote "arcade.lan"
[19:26:15.880] Using commit id "0ba0ca52957102ca3527cf479571617f0de6ed50" and quality "stable" for server
[19:26:15.882] Install and start server if needed
[19:26:34.124] Checking ssh with "ssh -V"
[19:26:34.160] > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
[19:26:34.161] Remote command length: 7544/8192 characters
[19:26:34.164] Running script with connection command: ssh -T -D 8350 arcade.lan powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -Command "powershell -ExecutionPolicy Unrestricted -NoLogo -NoProfile -NonInteractive -EncodedCommand $([Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('CmVjaG8gImI2NDIxNDJjZmY3MzogcnVubmluZyIKJFByb2dyZXNzUHJlZmVyZW5jZSA9ICdTaWxlbnRseUNvbnRpbnVlJwokY29tbWl0SWQgPSAnMGJhMGNhNTI5NTcxMDJjYTM1MjdjZjQ3OTU3MTYxN2YwZGU2ZWQ1MCcKCiR2c2NvZGVBcmNoID0gaWYgKCgkZW52OlBST0NFU1NPUl9BUkNISVRFQ1RVUkUgLWVxICdBTUQ2NCcpIC1vciAoJGVudjpQUk9DRVNTT1JfQVJDSElURUNUVVJFIC1lcSAnSUE2NCcpKSB7ICd4NjQnIH0gZWxzZSB7ICdpYTMyJyB9Cgokc2VydmVyUm9vdCA9IChKb2luLVBhdGggKFJlc29sdmUtUGF0aCB+KSAnLnZzY29kZS1zZXJ2ZXInKQokZW52OlZTQ09ERV9BR0VOVF9GT0xERVI9JHNlcnZlclJvb3QKJGxvZ2ZpbGUgPSAiJHNlcnZlclJvb3RcLiRjb21taXRJZC5sb2ciCiRzZXJ2ZXJEaXIgPSAiJHNlcnZlclJvb3RcYmluXCRjb21taXRJZCIKJHF1YWxpdHkgPSAnc3RhYmxlJwokdGVsZW1ldHJ5ID0gIiIKJGV4dGVuc2lvbnMgPSAiIgoKZnVuY3Rpb24gZ2V0U3NoZFBhcmVudFBpZCB7CiRjdXJyZW50UElEID0gJFBJRAp3aGlsZSAoJFRydWUpIHsKJHBhcmVudFBJRCA9IChHZXQtQ2ltSW5zdGFuY2Ugd2luMzJfcHJvY2VzcyB8ID8gcHJvY2Vzc2lkIC1lcSAkY3VycmVudFBJRCkucGFyZW50cHJvY2Vzc2lkCmlmICghJHBhcmVudFBJRCkgewplY2hvICJDb3VsZCBub3QgZmluZCBhbiBzc2hkIHBhcmVudCBvZiB0aGlzIHByb2Nlc3MiCmV4aXQgMAp9CgppZiAoKGdwcyAtSWQgJHBhcmVudFBJRCkuTmFtZSAtZXEgJ3NzaGQnKSB7CnJldHVybiAkcGFyZW50UElECn0KCiRjdXJyZW50UElEID0gJHBhcmVudFBJRAp9Cn0KCmZ1bmN0aW9uIGV4aXRJZk5lZWRlZCB7CmlmICgkbGF1bmNoZWRTZXJ2ZXJQaWQpIHsKaWYgKCEoZ3BzIC1JZCAkbGF1bmNoZWRTZXJ2ZXJQaWQpKSB7CmVjaG8gIlRoZSBsYXVuY2hlZCBzZXJ2ZXIgZGllZCwgZXhpdGluZyIKZXhpdCAwCn0KfSBlbHNlIHsKaWYgKCEoZ3BzIC1JZCAkc3NoZFBJRCkpIHsKZWNobyAiVGhlIHNzaGQgcGFyZW50IGRpZWQsIGV4aXRpbmciCmV4aXQgMAp9Cn0KfQoKZnVuY3Rpb24gRG93bmxvYWRTZXJ2ZXIgewplY2hvICJEb3dubG9hZGluZyBWUyBDb2RlIFNlcnZlciIKZWNobyAnYjY0MjE0MmNmZjczJSUxJSUnCiR3ZWJQYXJ0ID0gIiIKJHNlcnZlck5hbWUgPSAic2VydmVyLXdpbjMyLSR2c2NvZGVBcmNoIiArICR3ZWJQYXJ0CiRzcGxhdCA9IEB7ClVyaT0iaHR0cHM6Ly91cGRhdGUuY29kZS52aXN1YWxzdHVkaW8uY29tL2NvbW1pdDokY29tbWl0SWQvJHNlcnZlck5hbWUvJHF1YWxpdHkiClRpbWVvdXRTZWM9MjAKT3V0RmlsZT0idnNjb2RlLXNlcnZlci56aXAiClVzZUJhc2ljUGFyc2luZz0kVHJ1ZQp9CgpbTmV0LlNlcnZpY2VQb2ludE1hbmFnZXJdOjpTZWN1cml0eVByb3RvY29sID0gW05ldC5TZXJ2aWNlUG9pbnRNYW5hZ2VyXTo6U2VjdXJpdHlQcm90b2NvbCAtYm9yIFtOZXQuU2VjdXJpdHlQcm90b2NvbFR5cGVdOjpUbHMxMgpJbnZva2UtUmVzdE1ldGhvZCBAc3BsYXQKfQoKZnVuY3Rpb24gSW5zdGFsbFNlcnZlciB7CiRyYW5kb21EaXJOYW1lID0gW1N5c3RlbS5JTy5QYXRoXTo6R2V0UmFuZG9tRmlsZU5hbWUoKQokdG1wRGVzdCA9ICIkZW52OlRFTVBcJHJhbmRvbURpck5hbWUiCmVjaG8gIkV4cGFuZGluZyBzZXJ2ZXIgaW50byAkdG1wRGVzdCIKZWNobyAnYjY0MjE0MmNmZjczJSUyJSUnCkV4cGFuZC1BcmNoaXZlICJ2c2NvZGUtc2VydmVyLnppcCIgLURlc3RpbmF0aW9uUGF0aCAiJHRtcERlc3QiCk1vdmUtSXRlbSAiJHRtcERlc3RcdnNjb2RlLSpcKiIgLURlc3RpbmF0aW9uIC4KfQoKZnVuY3Rpb24gRG9DbGllbnREb3dubG9hZCB7CmVjaG8gIlRyaWdnZXIgY2xpZW50IHNlcnZlciBkb3dubG9hZCIKZWNobyBiNjQyMTQyY2ZmNzM6dHJpZ2dlcl9zZXJ2ZXJfZG93bmxvYWQKZWNobyBwbGF0Zm9ybT09d2luZG93cz09CmVjaG8gdnNjb2RlQXJjaD09JHZzY29kZUFyY2g9PQplY2hvIGRlc3RGb2xkZXI9PSRzZXJ2ZXJEaXI9PQplY2hvIGI2NDIxNDJjZmY3Mzp0cmlnZ2VyX3NlcnZlcl9kb3dubG9hZF9lbmQKCmVjaG8gIldhaXRpbmcgZm9yIGNsaWVudCB0byB0cmFuc2ZlciBzZXJ2ZXIgYXJjaGl2ZS4uLiIKZWNobyAiV2FpdGluZyBmb3IgJHNlcnZlckRpclx2c2NvZGUtc2NwLWRvbmUuZmxhZyBhbmQgdnNjb2RlLXNlcnZlci56aXAgdG8gZXhpc3QiCgp3aGlsZSgkVHJ1ZSkgewppZihUZXN0LVBhdGggIiRzZXJ2ZXJEaXJcdnNjb2RlLXNjcC1kb25lLmZsYWciKSB7CmlmKCEoVGVzdC1QYXRoICIkc2VydmVyRGlyXHZzY29kZS1zZXJ2ZXIuemlwIikpIHsKZWNobyAiRm91bmQgZmxhZyBidXQgbm90IHNlcnZlciB0YXIgLSBzZXJ2ZXIgdHJhbnNmZXIgZmFpbGVkIgplY2hvICJiNjQyMTQyY2ZmNzMjIzMxIyMiCmV4aXQgMAp9CgplY2hvICJGb3VuZCBmbGFnIGFuZCBzZXJ2ZXIgb24gaG9zdCIKZGVsICRzZXJ2ZXJEaXJcdnNjb2RlLXNjcC1kb25lLmZsYWcKYnJlYWsKfSBlbHNlIHsKU3RhcnQtU2xlZXAgLVNlY29uZHMgMwpleGl0SWZOZWVkZWQKfQp9Cn0KCiRzc2hkUElEID0gZ2V0U3NoZFBhcmVudFBpZAoKaWYoIShUZXN0LVBhdGggJHNlcnZlckRpcikpIHsKdHJ5IHsKJG51bGwgPSBOZXctSXRlbSAtSXRlbVR5cGUgRGlyZWN0b3J5ICRzZXJ2ZXJEaXIgLUZvcmNlIC1FcnJvckFjdGlvbiBTaWxlbnRseUNvbnRpbnVlCn0gY2F0Y2ggewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgZGlyZWN0b3J5LiAtICQoJF8uVG9TdHJpbmcoKSkiCnJldHVybgp9CgppZighKFRlc3QtUGF0aCAkc2VydmVyRGlyKSkgewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgZGlyZWN0b3J5LiIKcmV0dXJuCn0KfQoKY2QgJHNlcnZlckRpcgoKJGxvY2tGaWxlUGF0aCA9IChKb2luLVBhdGggIiRzZXJ2ZXJEaXIiICJ2c2NvZGUtcmVtb3RlLWxvY2suJGNvbW1pdElkIikKdHJ5IHsKJG51bGwgPSBOZXctSXRlbSAkbG9ja0ZpbGVQYXRoIC1JdGVtVHlwZSBGaWxlIC1FcnJvckFjdGlvbiBTaWxlbnRseUNvbnRpbnVlCn0gY2F0Y2ggewplY2hvICJDb3VsZCBub3QgY3JlYXRlIHZzY29kZS1zZXJ2ZXIgbG9jayBmaWxlLiAtICQoJF8uVG9TdHJpbmcoKSkiCnJldHVybgp9Cgp0cnkgewplY2hvICJBY3F1aXJpbmcgbG9jayBvbiAkbG9ja0ZpbGVQYXRoIgoKJGZpbGUgPSBbU3lzdGVtLmlvLkZpbGVdOjpPcGVuKCRsb2NrRmlsZVBhdGgsICdPcGVuJywgJ1JlYWQnLCAnTm9uZScpCn0gY2F0Y2ggewplY2hvICJJbnN0YWxsYXRpb24gYWxyZWFkeSBpbiBwcm9ncmVzcy4uLiAtICQoJF8uVG9TdHJpbmcoKSkiCmVjaG8gImI2NDIxNDJjZmY3MyMjMjQjIyIKcmV0dXJuCn0KCnRyeSB7CmVjaG8gIkxvb2tpbmcgZm9yIGV4aXN0aW5nIHNlcnZlciBpbiAkc2VydmVyRGlyIgppZihUZXN0LVBhdGggIiRzZXJ2ZXJEaXJcc2VydmVyLmNtZCIpIHsKZWNobyAidnNjb2RlLXNlcnZlciBhbHJlYWR5IGluc3RhbGxlZC4gU2tpcHBpbmcgZG93bmxvYWQuLi4iCn0gZWxzZSB7CnRyeSB7CkRvd25sb2FkU2VydmVyCn0gY2F0Y2ggewplY2hvICJGYWlsZWQgdG8gZG93bmxvYWQgJiBleHRyYWN0IHZzY29kZS1zZXJ2ZXIuIC0gJCgkXy5Ub1N0cmluZygpKSIKRG9DbGllbnREb3dubG9hZAp9CgpJbnN0YWxsU2VydmVyCgppZighKFRlc3QtUGF0aCAiJHNlcnZlckRpclxzZXJ2ZXIuY21kIikpIHsKZWNobyAiRmFpbGVkIHRvIGRvd25sb2FkICYgZXh0cmFjdCB2c2NvZGUtc2VydmVyLiIKZWNobyAiYjY0MjE0MmNmZjczIyMyNSMjIgpyZXR1cm4KfQp9CgppZiAoJGV4dGVuc2lvbnMgLW5lICIiKSB7CmVjaG8gIkluc3RhbGxpbmcgZXh0ZW5zaW9ucy4uLiIKJiAiJHNlcnZlckRpclxzZXJ2ZXIuY21kIiAkdGVsZW1ldHJ5ICAjID8/Cn0KCmlmKCEoR2V0LVByb2Nlc3Mgbm9kZSAtRXJyb3JBY3Rpb24gU2lsZW50bHlDb250aW51ZSB8IFdoZXJlLU9iamVjdCBQYXRoIC1tYXRjaCAkY29tbWl0SWQpKSB7CmlmKFRlc3QtUGF0aCAkbG9nZmlsZSkgewpkZWwgJGxvZ2ZpbGUKfQokc3BsYXQgPSBAewpGaWxlUGF0aCA9ICJwb3dlcnNoZWxsLmV4ZSIKV2luZG93U3R5bGUgPSAiaGlkZGVuIgpBcmd1bWVudExpc3QgPSBAKAoiLUV4ZWN1dGlvblBvbGljeSIsICJVbnJlc3RyaWN0ZWQiLCAiLU5vTG9nbyIsICItTm9Qcm9maWxlIiwgIi1Ob25JbnRlcmFjdGl2ZSIsICItYyIsICImIGAiJHNlcnZlckRpclxzZXJ2ZXIuY21kYCIgLS1ob3N0PTEyNy4wLjAuMSAtLWVuYWJsZS1yZW1vdGUtYXV0by1zaHV0ZG93biAtLXBvcnQ9MCAkdGVsZW1ldHJ5ICo+ICckbG9nZmlsZSciCikKUGFzc1RocnUgPSAkVHJ1ZQp9CmVjaG8gIlN0YXJ0aW5nIHNlcnZlciB3aXRoIGNvbW1hbmQuLi4gJiAnJHNlcnZlckRpclxzZXJ2ZXIuY21kJyAtLWhvc3Q9MTI3LjAuMC4xIC0tZW5hYmxlLXJlbW90ZS1hdXRvLXNodXRkb3duIC0tcG9ydD0wICR0ZWxlbWV0cnkgKj4gJyRsb2dmaWxlJyIKJGxhdW5jaGVkU2VydmVyUGlkID0gKFN0YXJ0LVByb2Nlc3MgQHNwbGF0KS5JRAp9IGVsc2UgewplY2hvICJ2c2NvZGUtc2VydmVyIHdpdGggJGNvbW1pdElkIGlzIGFscmVhZHkgcnVubmluZy4iCn0KCiRzcGxhdCA9IEB7ClBhdGggPSAkbG9nZmlsZQpQYXR0ZXJuID0gIkV4dGVuc2lvbiBob3N0IGFnZW50IGxpc3RlbmluZyBvbiAoXGQrKSIKfQoKJHRpbWVvdXREYXRlID0gKEdldC1EYXRlKS5BZGRTZWNvbmRzKDQpCndoaWxlICgoR2V0LURhdGUpIC1sdCAkdGltZW91dERhdGUpIHsKaWYoVGVzdC1QYXRoICRsb2dmaWxlKSB7CiRncm91cHMgPSAoU2VsZWN0LVN0cmluZyBAc3BsYXQpLk1hdGNoZXMuR3JvdXBzCmlmKCRncm91cHMpIHsKJHBvcnQgPSAkZ3JvdXBzWzFdLlZhbHVlCmJyZWFrCn0KfQpTdGFydC1TbGVlcCAtTWlsbGlzZWNvbmRzIDUwMAp9CgppZiAoISRwb3J0KSB7CmVjaG8gIlNlcnZlciBkaWQgbm90IHN0YXJ0IHN1Y2Nlc3NmdWxseS4gRnVsbCBzZXJ2ZXIgbG9nIGF0ICRsb2dmaWxlID4+PiIKY2F0ICRsb2dmaWxlCmVjaG8gIjw8PCBFbmQgb2Ygc2VydmVyIGxvZyIKZWNobyAiYjY0MjE0MmNmZjczIyMzMiMjIgpyZXR1cm4KfQp9IGNhdGNoIHsKZWNobyAidnNjb2RlLXNlcnZlciBmYWlsZWQgdG8gc3RhcnQuIC0gJCgkXy5Ub1N0cmluZygpKSIKfSBmaW5hbGx5IHsKJGZpbGUuQ2xvc2UoKQp9CgoKdHJ5IHsKJHdpblZlcnNpb24gPSAoR2V0LUNpbUluc3RhbmNlIFdpbjMyX09wZXJhdGluZ1N5c3RlbSkuVmVyc2lvbgp9IGNhdGNoIHsKZWNobyAiRmFpbGVkIHRvIGZpbmQgV2luZG93cyB2ZXJzaW9uIC0gJCgkXy5Ub1N0cmluZygpKSIKJHdpblZlcnNpb24gPSAidW5rbm93biIKfQoKZWNobyAiYjY0MjE0MmNmZjczOiBzdGFydCIKZWNobyAic3NoQXV0aFNvY2s9PSRlbnY6U1NIX0FVVEhfU09DSz09IgplY2hvICJhZ2VudFBvcnQ9PSRwb3J0PT0iCmVjaG8gIm9zUmVsZWFzZUlkPT13aW5kb3dzPT0iCmVjaG8gIm9zVmVyc2lvbj09JHdpblZlcnNpb249PSIKZWNobyAiYXJjaD09JHZzY29kZUFyY2g9PSIKZWNobyAicGxhdGZvcm09PXdpbmRvd3M9PSIKZWNobyAiYjY0MjE0MmNmZjczOiBlbmQiCgoKCmVjaG8gIkluc3RhbGwgc2NyaXB0IGlzICRwaWQsIHdhdGNoaW5nIHNzaGQgcGFyZW50ICRzc2hkUElEIgp3aGlsZSAoJFRydWUpIHsKZXhpdElmTmVlZGVkClN0YXJ0LVNsZWVwIDMwCn0K')))))"  # RemoteSSHConfigurationScript
[19:26:34.166] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[19:26:34.241] > 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> �]0;C:\WINDOWS\System32\cmd.exe�
[19:26:34.242] Got some output, clearing connection timeout
[19:26:34.247] > 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
[19:26:34.449] > DockerUser@arcade.lan's password: 
[19:26:34.449] Showing password prompt
[19:26:41.859] Got password response
[19:26:41.860] "install" wrote data to terminal: "******"
[19:26:41.872] > 
> 
[19:26:42.507] > #< CLIXML
> 
[19:26:42.516] > b642142cff73: running
> 
[19:26:47.880] > Could not find an sshd parent of this process
[19:26:47.887] > 
> <Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
> <Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCust
> omObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"
> ><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC
> ><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1
> "><TNRef RefId="0" /><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing m
> odules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T
> ><SR>-1</SR><SD> </SD></PR></MS></Obj><S S="Error">Get-CimInstance : Access deni
> ed _x000D__x000A_</S><S S="Error">At line:19 char:15_x000D__x000A_</S><S S="Erro
> r">+ $parentPID = (Get-CimInstance win32_process | ? processid -eq $curren ..._x
> 000D__x000A_</S><S S="Error">+               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_x000D
> __x000A_</S><S S="Error">    + CategoryInfo          : PermissionDenied: (root\c
> imv2:win32_process:String) [Get-CimInstance], CimException_x000D__x000A_</S><S S
> ="Error">    + FullyQualifiedErrorId : HRESULT 0x80041003,Microsoft.Management.I
> nfrastructure.CimCmdlets.GetCimInstanceCommand_x000D__x000A_</S><S S="Error"> _x
> 000D__x000A_</S></Objs>
[19:26:48.207] "install" terminal command done
[19:26:48.208] Install terminal quit with output: 000D__x000A_</S></Objs>
[19:26:48.208] Received install output: 000D__x000A_</S></Objs>
[19:26:48.209] Stopped parsing output early. Remaining text: 000D__x000A_</S></Objs>
[19:26:48.210] Failed to parse remote port from server output
[19:26:48.210] Resolver error: 
[19:26:48.216] ------

[roblourens]

On the remote, if you open powershell, are you able to run this command? (Get-CimInstance Win32_OperatingSystem).Version It's saying PermissionDenied for that command, but I don't think you should need admin privileges for that one as far as I know.

[ericblade]

logged into the remote with remote desktop:

logged into the remote via ssh:

... neither were run with specifically requesting admin. perhaps something in my openssh configuration is wonky? i just added the server from Add/Remove Components, rebooted, and then made sure the service was running in taskmanager, then used it.

[roblourens]

Are you the same user in both? In the remote desktop case is that an Admin powershell window?

[ericblade]

same user.. i'm pretty sure it was not an admin powershell, but i will re-run it just to make sure

So, it looks like I have permission to run that command when connected via RDP to the machine, but not when connected via SSHD .. not sure how that works exactly, I'm no expert in Windows permissions. I'm probably not even a novice in Windows permissions :)

[roblourens]

Can you try running this snippet on both ends?

$SecurityPrinciple = New-Object -TypeName System.Security.Principal.WindowsPrincipal -ArgumentList ([System.Security.Principal.WindowsIdentity]::GetCurrent())
$RolesHash = @{}
[System.Enum]::GetNames(“System.Security.Principal.WindowsBuiltInRole”) | ForEach-Object {
	$RolesHash[$_] = $SecurityPrinciple.IsInRole([System.Security.Principal.WindowsBuiltInRole]::$_)
}

$RolesHash

[System.Security.Principal.WindowsIdentity]::GetCurrent()

[ericblade]

From RDP

PS C:\WINDOWS\system32> $SecurityPrinciple = New-Object -TypeName System.Security.Principal.WindowsPrincipal -ArgumentList ([System.Security.Principal.WindowsIdentity]::GetCurrent())                                                          PS C:\WINDOWS\system32> $RolesHash = @{}                                                                                PS C:\WINDOWS\system32> [System.Enum]::GetNames("System.Security.Principal.WindowsBuiltInRole") | ForEach-Object {
>> $RolesHash[$_] = $SecurityPrinciple.IsInRole([System.Security.Principal.WindowsBuiltInRole]::$_)
>> }                                                                                                                    PS C:\WINDOWS\system32>                                                                                                 PS C:\WINDOWS\system32> $RolesHash
Name                           Value
----                           -----
Replicator                     False
PrintOperator                  False
PowerUser                      False
Guest                          False
AccountOperator                False
SystemOperator                 False
BackupOperator                 False
Administrator                  False
User                           True


PS C:\WINDOWS\system32>                                                                                                 PS C:\WINDOWS\system32> [System.Security.Principal.WindowsIdentity]::GetCurrent()                                    

AuthenticationType : NTLM
ImpersonationLevel : None
IsAuthenticated    : True
IsGuest            : False
IsSystem           : False
IsAnonymous        : False
Name               : ARCADE\dockeruser
Owner              : S-1-5-21-3583042812-2210650346-111016193-1004
User               : S-1-5-21-3583042812-2210650346-111016193-1004
Groups             : {S-1-5-21-3583042812-2210650346-111016193-513, S-1-1-0, S-1-5-32-545, S-1-5-4...}
Token              : 884
AccessToken        : Microsoft.Win32.SafeHandles.SafeAccessTokenHandle
UserClaims         : {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: ARCADE\dockeruser,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid:
                     S-1-5-21-3583042812-2210650346-111016193-1004,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid:
                     S-1-5-21-3583042812-2210650346-111016193-513,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid:
                     S-1-5-21-3583042812-2210650346-111016193-513...}
DeviceClaims       : {}
Claims             : {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: ARCADE\dockeruser,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid:
                     S-1-5-21-3583042812-2210650346-111016193-1004,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid:
                     S-1-5-21-3583042812-2210650346-111016193-513,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid:
                     S-1-5-21-3583042812-2210650346-111016193-513...}
Actor              :
BootstrapContext   :
Label              :
NameClaimType      : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
RoleClaimType      : http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid



PS C:\WINDOWS\system32>

from sshd

PS C:\Users\dockeruser> $SecurityPrinciple = New-Object -TypeName System.Security.Principal.WindowsPrincipal -ArgumentList ([System.Security.Principal.WindowsIdentity]::GetCurrent())
PS C:\Users\dockeruser> $RolesHash = @{}
PS C:\Users\dockeruser> [System.Enum]::GetNames("System.Security.Principal.WindowsBuiltInRole") | ForEach-Object {
>> $RolesHash[$_] = $SecurityPrinciple.IsInRole([System.Security.Principal.WindowsBuiltInRole]::$_)
>> }
PS C:\Users\dockeruser>
PS C:\Users\dockeruser> $RolesHash

Name                           Value
----                           -----
Replicator                     False
PrintOperator                  False
PowerUser                      False
Guest                          False
AccountOperator                False
SystemOperator                 False
BackupOperator                 False
Administrator                  False
User                           True


PS C:\Users\dockeruser>
PS C:\Users\dockeruser> [System.Security.Principal.WindowsIdentity]::GetCurrent()


AuthenticationType : NTLM
ImpersonationLevel : None
IsAuthenticated    : True
IsGuest            : False
IsSystem           : False
IsAnonymous        : False
Name               : ARCADE\dockeruser
Owner              : S-1-5-21-3583042812-2210650346-111016193-1004
User               : S-1-5-21-3583042812-2210650346-111016193-1004
Groups             : {S-1-5-21-3583042812-2210650346-111016193-513, S-1-1-0, S-1-5-32-545, S-1-5-2...}
Token              : 3052
AccessToken        : Microsoft.Win32.SafeHandles.SafeAccessTokenHandle
UserClaims         : {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: ARCADE\dockeruser, http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid: S-1-5-21-3583042812-2210650346-111016193-1004,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid: S-1-5-21-3583042812-2210650346-111016193-513, http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid: S-1-5-21-3583042812-2210650346-111016193-513...}
DeviceClaims       : {}
Claims             : {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: ARCADE\dockeruser, http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid: S-1-5-21-3583042812-2210650346-111016193-1004,
                     http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid: S-1-5-21-3583042812-2210650346-111016193-513, http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid: S-1-5-21-3583042812-2210650346-111016193-513...}
Actor              :
BootstrapContext   :
Label              :
NameClaimType      : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
RoleClaimType      : http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid



PS C:\Users\dockeruser>

[roblourens]

Thanks for trying that. I have no clue what's going on, I'll have to experiment some more.

[ericblade]

If it helps at all, it's a pretty basic installation of Windows 10 Pro, it's got Docker for Windows installed, a Plex Media Server, and a bunch of Docker services that handle home automation tasks. That's really about it. I decided I wanted to try VSCode remote to it, now that it supports Windows. ssh wouldn't work with the default account which has no password on it, so i used the account that was setup for Docker volume sharing (since Docker also doesn't work with accounts that have no password) ... i don't know what else I could add that might help.

[roblourens]

I can repro. Basically get-ciminstance will work locally but not through an ssh session. I didn't realize that the permissions model works like that and had only tested it locally in a non-admin account.

[jvihrial]

yes, I can repro this easily, ssh to windows box, open powershell and execute the command: (Get-CimInstance Win32_OperatingSystem).Version, you get back:
PS C:\Users\testuser> (Get-CimInstance Win32_OperatingSystem).Version

Get-CimInstance : Access denied
At line:1 char:2
+ (Get-CimInstance Win32_OperatingSystem).Version
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (root\cimv2:Win32_OperatingSystem:String) [Get-CimInstance], CimException
    + FullyQualifiedErrorId : HRESULT 0x80041003,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

[wpbrown]

Connecting via SSH is a network logon vs interactive logon locally or via RDP. I think the credentials of the SSH session can't be forwarded to the local COM server to use CIM.

[ericblade]

Confirming that the destination account is a Local Standard account type.

[wpbrown]

I'm reproducing with a Local Standard account. Local Admin account works fine.

[Conafmau]

Grant permission to execute Get-CimInstance, but still dont work.

Grant permission:
https://docs.bmc.com/docs/display/public/btco100/Setting+WMI+user+access+permissions+using+the+WMI+Control+Panel

New error:
...
[19:22:45.843] Received install output: dce0ba885507##32##
[19:22:45.845] Resolver error: The VS Code Server failed to start

[phit]

Is there any known workaround for this issue? Some patch I could try? Thanks.

[ericblade]

I don't know if anyone's found anything else out yet, but i made a second admin account on the machine. :|

[bluepotatoes]

I am having this exact same issue with CimInstance privileges. Haven't been able to find a workaround that works.

[metablaster]

Here is slightly different and shorter approach from what @faltrock-abone described: (+1 btw!)

1. Run compmgmt.msc as Administrator
2. Select WMI control node -> More actions -> properties
3. In the Security tab add only the standard user that you'll use for SSH
4. The rest is same, edit security property for this user:
   • Enable Account and Remote Enable rights \ applies to this namesapce and subnamespaces

What's the difference or why doing it this way?
WinRMRemoteWMIUsers__ group is added after you've setup WinRM (not everybody does), this way you skip that part:
https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections

Another difference is that you affect only single standard user account.

edit:
Another solution to affect multiple standard users would be to add specific users to Remote management users group, then add this group to WMI.
Why? this group has required permissions already set, you only add users to it, and add it to WMI security without additional steps that are needed for single user.

[FulChou]

hello, I get the same problem, I use vscode to connect my windows server in my MacPro by ssh. i can connect when the remote is Administrator, but no my own user account.
but, I can use ssh login with my own username by terminal.

this is log, when I try to connect my own username:

[15:25:40.663] Log Level: 2
[15:25:40.665] remote-ssh@0.65.1
[15:25:40.665] darwin x64
[15:25:40.666] SSH Resolver called for "ssh-remote+7b22686f73744e616d65223a2257494e2d363539503935564a49564c227d", attempt 1
[15:25:40.666] "remote.SSH.useLocalServer": false
[15:25:40.666] "remote.SSH.showLoginTerminal": false
[15:25:40.667] "remote.SSH.remotePlatform": {"18862_ocr":"linux","raspberrypi":"linux","inpluslab":"linux","WIN-659P95VJIVL_admin":"windows"}
[15:25:40.667] "remote.SSH.sshPath": undefined
[15:25:40.667] "remote.SSH.sshConfigurationFile": undefined
[15:25:40.667] "remote.SSH.useFlock": true
[15:25:40.667] "remote.SSH.lockfilesInTmp": false
[15:25:40.667] "remote.SSH.localServerDownload": auto
[15:25:40.667] "remote.SSH.remoteServerListenOnSocket": false
[15:25:40.668] "remote.SSH.showLoginTerminal": false
[15:25:40.668] "remote.SSH.defaultExtensions": []
[15:25:40.668] SSH Resolver called for host: WIN-659P95VJIVL
[15:25:40.668] Setting up SSH remote "WIN-659P95VJIVL"
[15:25:40.677] Using commit id "c185983a683d14c396952dd432459097bc7f757f" and quality "stable" for server
[15:25:40.681] Install and start server if needed
[15:25:42.151] Checking ssh with "ssh -V"
[15:25:42.158] > OpenSSH_8.1p1, LibreSSL 2.7.3

[15:25:42.161] Remote command length: 5986/8192 characters
[15:25:42.161] Running script with connection command: ssh -T -D 57770 -o ConnectTimeout=15 'WIN-659P95VJIVL' powershell
[15:25:42.923] > ZhouFu@172.18.166.44's password:
[15:25:42.923] Got some output, clearing connection timeout
[15:25:42.924] Showing password prompt
[15:25:56.234] Got password response
[15:25:56.234] "install" wrote data to terminal: "**********"
[15:25:56.247] >
[15:25:59.027] > Windows PowerShell

��Ȩ���� (C) Microsoft Corporation����������Ȩ����

(base) PS C:\Users\ZhouFu>
(base) PS C:\Users\ZhouFu> $uuid="c82d9a7e983f"
(base) PS C:\Users\ZhouFu> "${uuid}: running"
c82d9a7e983f: running
(base) PS C:\Users\ZhouFu> "c82d9a7e983f: pauseLog"
c82d9a7e983f: pauseLog
[15:26:00.136] > m
[15:26:00.142] > ain
[15:26:05.111] > gcim : �ܾ�����
����λ�� ��:4 �ַ�: 6

• $u_=(gcim win32_process | ? processid -eq $t_).parentprocessid

•  ~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : PermissionDenied: (root\cimv2:win32_process:String) [Get-CimInstance], CimException
  • FullyQualifiedErrorId : HRESULT 0x80041003,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand

[15:26:05.119] > no sshd parent proc
[15:26:05.127] >
[15:26:05.448] "install" terminal command done
[15:26:05.448] Install terminal quit with output: no sshd parent proc
[15:26:05.448] Received install output: no sshd parent proc
[15:26:05.449] Stopped parsing output early. Remaining text: no sshd parent proc
[15:26:05.449] Failed to parse remote port from server output
[15:26:05.452] Resolver error: Error:
at Function.Create (/Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:1:64328)
at Object.t.handleInstallOutput (/Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:1:63022)
at q (/Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:1:296373)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async /Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:1:294221
at async Object.t.withShowDetailsEvent (/Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:1:407055)
at async Object.t.resolve (/Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:1:297912)
at async /Users/vincent/.vscode/extensions/ms-vscode-remote.remote-ssh-0.65.1/out/extension.js:127:110485
[15:26:05.476] ------

I can get success when using Administrator

thank you for your help !!!

[bobwng]

Met exactly same issue as @CSU-FulChou mentioned above. Administrator account is OK but other admin group users are not.

Tried the solution @metablaster provided above, the issue is still there.

[Silver-Fang]

Same issue. Still not fixed for 21 months???

[Sidneys1]

Steps that worked for me:

1. Open compmgmt.msc as an elevated user.
2. Expand "Services and Applications", select "WMI Control", then right-click "WMI Control"→"Properties"
3. Select the "Security" tab and click the "Security" button.
4. In the "Security for Root" window that appears, click "Advanced".
5. Click "Add". Click "Select a principal".
6. Type "Remote Management Users" and click "Validate names". This will resolve the group name, then click OK.
7. Select "Applies to:"→"This namespace and subnamespaces". Check all permissions and click OK.
8. Click OK out through all of the remaining dialogs.
9. Add your user to the "Remote Management Users" group if you haven't already.
10. Restart the OpenSSH Server service (sshd).

[carlos-vl]

I am having the same issue, the host is a computer from my company and I cannot do the suggested changes.
Is there any progress on this?

[Mickychen00]

I have the same issue when I use non Administrator account. But Administrator account is ok.

[grtwje]

This issue makes me sad. Since it's "On Deck," I check every new release to see if it's fixed. And it is not.

My workaround is to ssh to bash under WSL2 on the Windows box. The user account does not need administrator for this access method. (Well, I guess you'll need it to install WSL2.)

[burkenyo]

Hi @grtwje, you can also try some of the above workarounds such as @metablaster’s to connect to the windows side. It does require some mucking around, so an OOB solution build into the extension would be ideal!

[cutec-chris]

I am having the same issue, the host is a computer from my company and I cannot do the suggested changes. Is there any progress on this?

same here, why this issue has so low priority ?

[Silver-Fang]

I am having the same issue, the host is a computer from my company and I cannot do the suggested changes. Is there any progress on this?

same here, why this issue has so low priority ?

Because they believe that very few people will choose Windows instead of Linux as the SSH server, and thus they somewhat don't care about Windows users. They betrayed Microsoft.

[deisi]

like +1 for this as a fix worthy issue. The workaround from @metablaster works, but changing user permissions might not be possible in a coporate environment, and thats also where windows servers with limited permissions are most likely to occur.

Anyway @roblourens is there any idear how to fix this? I could imagine this is a wontfix as the issue seems to be with how permissions are set within windows by default here.

[tom-inetum-realdolmen]

Just leaving a message for those coming after me
Root cause is that by default WMI does not allow queries to be executed remotely, which is exactly what you do when you connect to a windows server via WinRM OR via OpenSSH..
To circumvent the issue, you need to grant your nonadmin users the privilege to remotely query wmi, (the root\cimv2 namespace in this scenario but you might also want to enable other namespaces).

• Open Computer Management -> System Tools -> Local Users and Groups
• Create a new Local group on the Windows Server/Windows Client (let's call it Remote wmi enabled) and add any accounts in it that must be allowed to query wmi remotely.
• Open Services and Applications
• Right click WMI Control and select Properties
• Go to the Security tab and select the namespace you want to modify (again, root\cimv2 is the bare minimum needed for vscode to work but you might want to allow other namespaces)
• Add the newly created group to the list and check the option Remote Enable
• Hit OK a couple of times
• Make sure all processes of the target user are logged off from the system before retrying: since you add the user to a group it is mandatory in windows to do a complete 'login' again and refresh your group memberships!
• retry and all should be good

[DanielLaberge]

Confirm that metablaster's approach worked for me.

While I understand vs-code cannot do this setup automatically, I believe that when this situation is detected during setup, it should direct users to a help article with official guidance on how to configure this properly with minimal permissions.

Here is slightly different and shorter approach from what @faltrock-abone described: (+1 btw!)

1. Run compmgmt.msc as Administrator

2. Select WMI control node -> More actions -> properties

3. In the Security tab add only the standard user that you'll use for SSH

4. The rest is same, edit security property for this user:

   • Enable Account and Remote Enable rights \ applies to this namesapce and subnamespaces

What's the difference or why doing it this way? WinRMRemoteWMIUsers__ group is added after you've setup WinRM (not everybody does), this way you skip that part: https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections

Another difference is that you affect only single standard user account.

edit: Another solution to affect multiple standard users would be to add specific users to Remote management users group, then add this group to WMI. Why? this group has required permissions already set, you only add users to it, and add it to WMI security without additional steps that are needed for single user.

[chhex]

@tom-inetum-realdolmen Thanks a lot for the detailed guide , which worked for as described, very helpful

[davetapley]

#2648 (comment) visually 😁

[TUstudents]

Not fixed in VSCode Version: 1.82.2

[Niketin]

I'm using VSCode 1.85.1 and I am also facing this problem.

[alexchandel]

#2648 (comment) visually 😁

I just wanted to say this is the best documentation I have ever seen.

However, it did not full fix the issue for me. It only changed the error from:

<Objs Version="1.1.0.1"
  xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <S S="Error">gcim : Access denied _x000D__x000A_</S>
  <S S="Error">At line:52 char:6_x000D__x000A_</S>
  <S S="Error">+ $u_=(gcim win32_process | ? processid -eq $t_).parentprocessid_x000D__x000A_</S>
  <S S="Error">+      ~~~~~~~~~~~~~~~~~~_x000D__x000A_</S>
  <S S="Error">    + CategoryInfo          : PermissionDenied: (root\cimv2:win32_process:String) [Get-CimInstance], CimException_x000D__x000A_</S>
  <S S="Error">    + FullyQualifiedErrorId : HRESULT 0x80041003,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand_x000D__x000A_</S>
  <S S="Error"> _x000D__x000A_</S>
</Objs>

to:

<Objs Version="1.1.0.1"
  xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <S S="Error">gcim : Invalid class _x000D__x000A_</S>
  <S S="Error">At line:52 char:6_x000D__x000A_</S>
  <S S="Error">+ $u_=(gcim win32_process | ? processid -eq $t_).parentprocessid_x000D__x000A_</S>
  <S S="Error">+      ~~~~~~~~~~~~~~~~~~_x000D__x000A_</S>
  <S S="Error">    + CategoryInfo          : MetadataError: (root\cimv2:win32_process:String) [Get-CimInstance], CimException_x000D__x000A_</S>
  <S S="Error">    + FullyQualifiedErrorId : HRESULT 0x80041010,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand_x000D__x000A_</S>
  <S S="Error"> _x000D__x000A_</S>
</Objs>

\x0D\x0A is CRLF and seems like a red herring, as this is the only reference I can find for x000D__x000A and it's completely irrelevant, meaning this error message is just not decoded correctly.

Restarting sshddid not fix it.

EDIT: restarting the computer was required to finish the fix. Go figure.