Steps to Reproduce:
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] [email protected]
[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] > [email protected]'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] ------
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.
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.
Are you the same user in both? In the remote desktop case is that an Admin powershell window?
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 :)
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()
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>
Thanks for trying that. I have no clue what's going on, I'll have to experiment some more.
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.
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.
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
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.
Confirming that the destination account is a Local Standard account type.
I'm reproducing with a Local Standard account. Local Admin account works fine.
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
Is there any known workaround for this issue? Some patch I could try? Thanks.
I don't know if anyone's found anything else out yet, but i made a second admin account on the machine. :|
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.
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.
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.
I'm reproducing with a Local Standard account. Local Admin account works fine.
Thank you for a temporary solution.
I fixed this for my setup (connecting to Win10 Pro) with the following steps:
net localgroup WinRMRemoteWMIUsers__ /add in a privileged command lineAdd-LocalGroupMember -Group WinRMRemoteWMIUsers__mmc as an administratorEt voilá, remote SSH connect works in VSCode with a non-administrator local account.
That's great, finding a path there... now can we find a way to make that simpler / automatic ? :-D
Most helpful comment
I fixed this for my setup (connecting to Win10 Pro) with the following steps:
net localgroup WinRMRemoteWMIUsers__ /addin a privileged command lineAdd-LocalGroupMember -Group WinRMRemoteWMIUsers__mmcas an administratorEt voilá, remote SSH connect works in VSCode with a non-administrator local account.