microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.66k stars 287 forks source link

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

Open ericblade opened 4 years ago

ericblade commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

logged into the remote with remote desktop:

image

logged into the remote via ssh:

image

... 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 commented 4 years ago

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

ericblade commented 4 years ago

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

image

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ericblade commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

wpbrown commented 4 years ago

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

Conafmau commented 4 years ago

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 commented 4 years ago

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

ericblade commented 4 years ago

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

wpbrown commented 4 years ago

There are 2 lines in the Powershell payload that should be replaced with non-WMI alternatives:

$parentPID = (Get-CimInstance win32_process | ? processid -eq $currentPID).parentprocessid
$winVersion = (Get-CimInstance Win32_OperatingSystem).Version

I think getting this working is important because the sshd service is not UAC-aware. If you log in with an admin user via SSH you automatically have full admin rights on all your processes (i.e your vscode server and all of its children. Unlike an interactive desktop logon to admin user with UAC enabled where you still have to elevate via UAC to have full admin rights on that process tree.

One interesting possibility would be an option to have the vscode server drop privileges when it starts up for admin users.

wpbrown commented 4 years ago

I tried monkey patching out the WMI usage. Then it tries to launch the server. The server exits with exit code 15. I checked the server log, it just has the visual studio product family warning and doesnt get to print the IP address or any other messages.

burkenyo commented 4 years ago

What about getting the version directly from .Net: [System.Environment]::OSVersion.Version? Parent process is trickier, because I don't know how to do this with vanilla .Net/PS without WMI.

ByungjunKim commented 4 years ago

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

Thank you for a temporary solution.

ghost commented 4 years ago

I fixed this for my setup (connecting to Win10 Pro) with the following steps:

Et voilá, remote SSH connect works in VSCode with a non-administrator local account.

ericblade commented 4 years ago

That's great, finding a path there... now can we find a way to make that simpler / automatic ? :-D

bluepotatoes commented 3 years ago

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

metablaster commented 3 years ago

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 commented 3 years ago

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 win32process | ? 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 image

thank you for your help !!!

bobwng commented 3 years ago

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.

Ebola-Chan-bot commented 2 years ago

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

Sidneys1 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

grtwje commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 ?

Ebola-Chan-bot commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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).

DanielLaberge commented 1 year ago

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 commented 1 year ago

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

davetapley commented 1 year ago

https://github.com/microsoft/vscode-remote-release/issues/2648#issuecomment-1307510113 visually 😁

10_1_0_60
TUstudents commented 12 months ago

Not fixed in VSCode Version: 1.82.2

Niketin commented 9 months ago

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

alexchandel commented 8 months ago

#2648 (comment) visually 😁

10_1_0_60

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.

maxbeer99 commented 1 month ago

#2648 (comment) visually 😁

Least convoluted Windows solution, but thanks!

paramendula commented 6 days ago

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`).

Worked for me. VS Code version: 1.94.2 Has connected to Windows 11 Guest OS(virt-manager, OpenSSH) successfully