7 ms·

PowerShell Remoting

80 points by axiomdata316 8y ago

tyingq 8y ago
"The listener that is created when you enable PowerShell Remoting is over HTTP. You are able also to configure WinRM over HTTPS" Doesn't seem like a good idea to default to plaintext.
- 13of40 8y ago
  It's not plain text. The traffic is still encrypted by winrm.
  - tyingq 8y ago
    Ahh. Would be a good note in that area of the article.
    - newman314 8y ago
      I was curious about the details and did some digging. "Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key." https://docs.microsoft.com/en-us/powershell/scripting/setup/winrmsecurity?view=powershell-6#encryption-and-transport-protocols https://docs.microsoft.com/en-us/powershell/scripting/setup/...
      - genericid 8y ago
        Then what's the point of using HTTPS? Heating the room?
        jodrellblank 8y ago
        See my other comment, but a) it encrypts more of the packets, b) helps with validating correct server, c) encrypts even if you end up authenticating without Kerberos somehow.
        srinathgs 8y ago
        When using HTTP for remoting, headers are not encrypted. But body is always encrypted when using NTLM, CredSSP or Kerberos - the GSSAPI supported protocols. If user doesn't want to use these and opts for basic auth or some other protocol that doesn't have encryption specified, https is useful.
- jodrellblank 8y ago
  It's typical Microsoft engineering, and I say that as a frequent defender of powershell here. It's encrypted, except when it isn't, except on Tuesdays when it is. https://www.reddit.com/r/PowerShell/comments/97oxox/comment/e4blfgj https://www.reddit.com/r/PowerShell/comments/97oxox/comment/... "Just an FYI not all psremoting traffic is encrypted when using http. Message encryption is done using the authenticated context which varies based on what auth was actually used. For example Basic auth has no authenticated context in SSPI so has no encryption. NTLM (fallback if kerb is not available) is next to useless as it is based on RC4 which is considered broken today. Kerberos should be using AES if configured correctly but older environment may have older insecure algorithms set up if the config is mismanaged on the domain level. CredSSP uses the TLS context that is set up in the auth so is similar to using HTTPS. When using https you not only get a more consistent and secure encryption mechanism on all auth methods. You also get encryption on the whole TCP packet that is sent to the client, whereas http message only encryption encrypts the message body." And "My understanding of the issue is that WinRM can do more than just Powershell Remoting (for example there are also Python libraries that run on Linux machines to interface with WinRM which I'm assuming do something different to PS remoting since PS is not native/required on those platforms). So if you are doing ONLY Powershell Remoting you're probably fine with HTTP, but if you're doing anything else then it could be exposed via HTTP WinRM. So HTTPS is still recommended. tl;dr - All Powershell Remoting is WinRM, not all WinRM traffic is PS Remoting." https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encryption_question_xpost_from_rpowershell/ https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encr... And I think lots of people couldn't get a straight answer on this and it came up on the recent MCP Insider AMA. First 3 minutes of video 2 "it's secure, use it [...] tell 'em Jeffrey Snover told you, go do it". "Also, for more information on security when remoting read the powershell.org free e-book, Secrets of PowerShell Remoting.*" https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/cqzj4l2 https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/...
  - userbinator 8y ago
    It's typical Microsoft engineering What surprises me the most is they could've used the existing (also quite over-engineered, but existing nonetheless) MSRPC infrastructure for this, like what psexec does, but chose to use a completely different set of technologies once again.
reificator 8y ago
The article is about powershell to powershell remoting. I like powershell itself fairly well, but I just feel so much more comfortable in bash/zsh and more importantly the environment around them. I'm interested to see whether Windows SSH servers become more viable after ConPTY[0] is widely available. [0]: https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/ https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...
- 13of40 8y ago
  One benefit you get with powershell to powershell remoting is that the output of the commands come back as objects rather than text. You can even use "implicit remoting" (not sure if that's the marketing term) to make the remoting part of it transparent to your automation - see Import-PSSession.
  - reificator 8y ago
    That's a pretty cool feature, but I don't often remote into machines and then want to do the processing locally. Maybe that's because I don't have this feature, but I've never felt like I wanted to. Usually I just treat the client like a dumb terminal. I'd bet a project like Ansible could use something like that to great effect though.
    - tcbawo 8y ago
      From what I understand, PowerShell has been open-sourced and ported to Linux. Are non-Windows users adopting it? It's probably facing a long climb. Having 30+ years of productivity hacks is tough to compete with.
      - reificator 8y ago
        Part of it has, yeah. Personally I use it fairly frequently for scripting tasks on Windows, but have yet to have the urge to install it on anything else.
      - 8y ago
hobs 8y ago
I love powershell, but I will say the troubleshooting the remoting aspect of it suuuuucks. There were plenty of people cheering when they say they could ssh from powershell to a win box running powershell, just because of how annoying it is.
- Analemma_ 8y ago
  Trying to open a remote PowerShell session into a Windows VM running in Azure is agony. This seems like the most basic, fundamental operation you could imagine for an IaaS platform, particularly when you wrote all the components involved, and it’s nearly impossible.
  - equalunique 8y ago
    I haven't tried doing this with Azure, but if it involves setting up PowerShell Remoting for local accounts and non-domain computers, then I can see why it would be a hassle.
arminiusreturns 8y ago
Pywinrm is your friend if you are a nix person.
- reificator 8y ago
  That's a good tip, I'll check that out. Still hoping for SSH server support though...
  - xenophonf 8y ago
    I've installed and run OpenSSH via Cygwin on Windows systems going back to Windows Server 2003 at least. I think Cygwin provides a better UX than WSL, and its deployment is easily automated.
newman314 8y ago
Given that my company pushes things out using GPO, I'm trying to figure out if we are missing something by not leveraging PS Remoting. Does anyone have any use cases where PS Remoting would be more useful?
- nineteen999 8y ago
  Ansible supports powershell remoting. In a past role I used it to install SQL Server and other software packages on Windows servers. I've also used it to install VMware vCenter and all its dependencies, pGina etc. A bit clunky to set up but it works. I'd rather use SSH than WinRM though, which should be possible in the future now that MS has added SSH support to Windows.
- wolfspider 8y ago
  I use it for auto-deployment using Team Services into IIS. There is a plug-in for powershell remoting which works great for this and the client can be installed on a local vm or computer. You can of course start any other workflows from there too. It’s free so no need to do octodeploy or anything like that. Usually I also have it send a message to a slack channel when complete and start the deployment through the web: https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy/powershell-on-target-machines?view=vsts https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy...
nunez 8y ago
Remoting is SSH, but with much much MUCH more bulk (because it transfers full objects over the wire and uses SOAP as its wire protocol; see here: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_ws-management_cmdlets?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/microsoft... Now that Windows 10 and above support native SSH with a somewhat-real pseudo terminal, we can probably just use SSH instead in the next year or two without having to pay Bitvise a ton of cash
- userbinator 8y ago
  Note that Windows has had a similar capability to SSH for many years, but it's unfortunately not so well-known: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec https://docs.microsoft.com/en-us/sysinternals/downloads/psex... ("ps" prefix is unrelated to PowerShell, in fact I think this utility predates it.) It uses DCE-RPC which is not trivial, but I believe it is certainly more compact than SOAP and such. The main advantage is the server component is built-in.
  - Something1234 8y ago
    For the curious, https://en.wikipedia.org/wiki/Distributed_Computing_Environment https://en.wikipedia.org/wiki/Distributed_Computing_Environm... It sounds super complex to setup.
    - xenophonf 8y ago
      psexec is trivial to install and use: just download and run. At worst you might need to enable the RPC ports in the Windows firewall, which is also easy (even at scale thanks to GPO).
      - cm2187 8y ago
        But is there anything to install or setup on a windows server other than opening a port? Also does it require the server to be domain joined?
geophile 8y ago
Along the same lines: https://github.com/geophile/osh https://github.com/geophile/osh Osh (Object shell) is a command-line utility for running sequences of operations connected by a pipe-like construct. Objects are piped, not strings. Included in the sequence of operations may be remote sequences of command, which run on all nodes of a cluster. For example, if you have configured a cluster named foo, then you can get the pid and commandline of every node of your cluster like this: osh @foo [ ps ^ f 'p: (p.pid, p.commandline)' ] $ - osh: Invokes the interpreter - @foo [ ... ]: Run the bracketed commands on every node of cluster foo. - ps: The osh ps command, which yields a stream of Process objects. - ^: The osh pipe symbol - f: Function application. The function in this case takes a Process p, and returns a tuple containing the process's pid and command line. - $: Print the contents of the input stream, one per line. This is a python tool, so the stuff piped between operations are python objects.
- sjellis 8y ago
  I casually follow the development of the Elvish shell, which uses structured data, and is written in Go: https://elv.sh/ https://elv.sh/ The latest release has a package manager for plugins, so hopefully we'll see more support for remote stuff through that route. PowerShell has some great ideas, but it seems doomed to mostly be a quirk of Windows at this point. I'd really love to see a more modern shell than bash get adoption across the industry.
  - geophile 8y ago
    Hadn't heard about Elvish, thanks for the reference. I've thought about a new version of osh, making it less of a command-line utility, and more of a shell. What do you think would be the main properties of a "more modern shell"? Do you think it is OK if this shell drags in a Python interpreter?
madmulita 8y ago
font-weight: 300; Why do they insist on making the text hard to read?
ChicagoDave 8y ago
I worked at a client that manually pulled data from 70+ remote servers every morning to combine into a financial report. I enabled ps-remoting, wrote a bunch of scripts, and turned this process into an automated batch job that took 3 minutes. One of those odd jobs that was a lot of fun.
equalunique 8y ago
I can appreciate the clear explanation of Powershell Remoting in this guide. It was a big part of one of my previous jobs. It is a pathway to basic dev-ops things in a Windows environment.

80 points by axiomdata316 8y ago

"The listener that is created when you enable PowerShell Remoting is over HTTP. You are able also to configure WinRM over HTTPS" Doesn't seem like a good idea to default to plaintext.

13of40 8y ago
It's not plain text. The traffic is still encrypted by winrm.
- tyingq 8y ago
  Ahh. Would be a good note in that area of the article.
  - newman314 8y ago
    I was curious about the details and did some digging. "Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key." https://docs.microsoft.com/en-us/powershell/scripting/setup/winrmsecurity?view=powershell-6#encryption-and-transport-protocols https://docs.microsoft.com/en-us/powershell/scripting/setup/...
    - genericid 8y ago
      Then what's the point of using HTTPS? Heating the room?
      - jodrellblank 8y ago
        See my other comment, but a) it encrypts more of the packets, b) helps with validating correct server, c) encrypts even if you end up authenticating without Kerberos somehow.
        srinathgs 8y ago
        When using HTTP for remoting, headers are not encrypted. But body is always encrypted when using NTLM, CredSSP or Kerberos - the GSSAPI supported protocols. If user doesn't want to use these and opts for basic auth or some other protocol that doesn't have encryption specified, https is useful.
jodrellblank 8y ago
It's typical Microsoft engineering, and I say that as a frequent defender of powershell here. It's encrypted, except when it isn't, except on Tuesdays when it is. https://www.reddit.com/r/PowerShell/comments/97oxox/comment/e4blfgj https://www.reddit.com/r/PowerShell/comments/97oxox/comment/... "Just an FYI not all psremoting traffic is encrypted when using http. Message encryption is done using the authenticated context which varies based on what auth was actually used. For example Basic auth has no authenticated context in SSPI so has no encryption. NTLM (fallback if kerb is not available) is next to useless as it is based on RC4 which is considered broken today. Kerberos should be using AES if configured correctly but older environment may have older insecure algorithms set up if the config is mismanaged on the domain level. CredSSP uses the TLS context that is set up in the auth so is similar to using HTTPS. When using https you not only get a more consistent and secure encryption mechanism on all auth methods. You also get encryption on the whole TCP packet that is sent to the client, whereas http message only encryption encrypts the message body." And "My understanding of the issue is that WinRM can do more than just Powershell Remoting (for example there are also Python libraries that run on Linux machines to interface with WinRM which I'm assuming do something different to PS remoting since PS is not native/required on those platforms). So if you are doing ONLY Powershell Remoting you're probably fine with HTTP, but if you're doing anything else then it could be exposed via HTTP WinRM. So HTTPS is still recommended. tl;dr - All Powershell Remoting is WinRM, not all WinRM traffic is PS Remoting." https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encryption_question_xpost_from_rpowershell/ https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encr... And I think lots of people couldn't get a straight answer on this and it came up on the recent MCP Insider AMA. First 3 minutes of video 2 "it's secure, use it [...] tell 'em Jeffrey Snover told you, go do it". "Also, for more information on security when remoting read the powershell.org free e-book, Secrets of PowerShell Remoting.*" https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/cqzj4l2 https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/...
- userbinator 8y ago
  It's typical Microsoft engineering What surprises me the most is they could've used the existing (also quite over-engineered, but existing nonetheless) MSRPC infrastructure for this, like what psexec does, but chose to use a completely different set of technologies once again.

reificator 8y ago

The article is about powershell to powershell remoting. I like powershell itself fairly well, but I just feel so much more comfortable in bash/zsh and more importantly the environment around them. I'm interested to see whether Windows SSH servers become more viable after ConPTY[0] is widely available. [0]: https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/ https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...

13of40 8y ago
One benefit you get with powershell to powershell remoting is that the output of the commands come back as objects rather than text. You can even use "implicit remoting" (not sure if that's the marketing term) to make the remoting part of it transparent to your automation - see Import-PSSession.
- reificator 8y ago
  That's a pretty cool feature, but I don't often remote into machines and then want to do the processing locally. Maybe that's because I don't have this feature, but I've never felt like I wanted to. Usually I just treat the client like a dumb terminal. I'd bet a project like Ansible could use something like that to great effect though.
  - tcbawo 8y ago
    From what I understand, PowerShell has been open-sourced and ported to Linux. Are non-Windows users adopting it? It's probably facing a long climb. Having 30+ years of productivity hacks is tough to compete with.
    - reificator 8y ago
      Part of it has, yeah. Personally I use it fairly frequently for scripting tasks on Windows, but have yet to have the urge to install it on anything else.
    - 8y ago

hobs 8y ago

I love powershell, but I will say the troubleshooting the remoting aspect of it suuuuucks. There were plenty of people cheering when they say they could ssh from powershell to a win box running powershell, just because of how annoying it is.

Analemma_ 8y ago
Trying to open a remote PowerShell session into a Windows VM running in Azure is agony. This seems like the most basic, fundamental operation you could imagine for an IaaS platform, particularly when you wrote all the components involved, and it’s nearly impossible.
- equalunique 8y ago
  I haven't tried doing this with Azure, but if it involves setting up PowerShell Remoting for local accounts and non-domain computers, then I can see why it would be a hassle.

arminiusreturns 8y ago

Pywinrm is your friend if you are a nix person.

reificator 8y ago
That's a good tip, I'll check that out. Still hoping for SSH server support though...
- xenophonf 8y ago
  I've installed and run OpenSSH via Cygwin on Windows systems going back to Windows Server 2003 at least. I think Cygwin provides a better UX than WSL, and its deployment is easily automated.

newman314 8y ago

Given that my company pushes things out using GPO, I'm trying to figure out if we are missing something by not leveraging PS Remoting. Does anyone have any use cases where PS Remoting would be more useful?

nineteen999 8y ago
Ansible supports powershell remoting. In a past role I used it to install SQL Server and other software packages on Windows servers. I've also used it to install VMware vCenter and all its dependencies, pGina etc. A bit clunky to set up but it works. I'd rather use SSH than WinRM though, which should be possible in the future now that MS has added SSH support to Windows.
wolfspider 8y ago
I use it for auto-deployment using Team Services into IIS. There is a plug-in for powershell remoting which works great for this and the client can be installed on a local vm or computer. You can of course start any other workflows from there too. It’s free so no need to do octodeploy or anything like that. Usually I also have it send a message to a slack channel when complete and start the deployment through the web: https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy/powershell-on-target-machines?view=vsts https://docs.microsoft.com/en-us/vsts/pipelines/tasks/deploy...

nunez 8y ago

Remoting is SSH, but with much much MUCH more bulk (because it transfers full objects over the wire and uses SOAP as its wire protocol; see here: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_ws-management_cmdlets?view=powershell-5.1 https://docs.microsoft.com/en-us/powershell/module/microsoft... Now that Windows 10 and above support native SSH with a somewhat-real pseudo terminal, we can probably just use SSH instead in the next year or two without having to pay Bitvise a ton of cash

userbinator 8y ago
Note that Windows has had a similar capability to SSH for many years, but it's unfortunately not so well-known: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec https://docs.microsoft.com/en-us/sysinternals/downloads/psex... ("ps" prefix is unrelated to PowerShell, in fact I think this utility predates it.) It uses DCE-RPC which is not trivial, but I believe it is certainly more compact than SOAP and such. The main advantage is the server component is built-in.
- Something1234 8y ago
  For the curious, https://en.wikipedia.org/wiki/Distributed_Computing_Environment https://en.wikipedia.org/wiki/Distributed_Computing_Environm... It sounds super complex to setup.
  - xenophonf 8y ago
    psexec is trivial to install and use: just download and run. At worst you might need to enable the RPC ports in the Windows firewall, which is also easy (even at scale thanks to GPO).
    - cm2187 8y ago
      But is there anything to install or setup on a windows server other than opening a port? Also does it require the server to be domain joined?

geophile 8y ago

Along the same lines: https://github.com/geophile/osh https://github.com/geophile/osh Osh (Object shell) is a command-line utility for running sequences of operations connected by a pipe-like construct. Objects are piped, not strings. Included in the sequence of operations may be remote sequences of command, which run on all nodes of a cluster. For example, if you have configured a cluster named foo, then you can get the pid and commandline of every node of your cluster like this: osh @foo [ ps ^ f 'p: (p.pid, p.commandline)' ] $ - osh: Invokes the interpreter - @foo [ ... ]: Run the bracketed commands on every node of cluster foo. - ps: The osh ps command, which yields a stream of Process objects. - ^: The osh pipe symbol - f: Function application. The function in this case takes a Process p, and returns a tuple containing the process's pid and command line. - $: Print the contents of the input stream, one per line. This is a python tool, so the stuff piped between operations are python objects.

sjellis 8y ago
I casually follow the development of the Elvish shell, which uses structured data, and is written in Go: https://elv.sh/ https://elv.sh/ The latest release has a package manager for plugins, so hopefully we'll see more support for remote stuff through that route. PowerShell has some great ideas, but it seems doomed to mostly be a quirk of Windows at this point. I'd really love to see a more modern shell than bash get adoption across the industry.
- geophile 8y ago
  Hadn't heard about Elvish, thanks for the reference. I've thought about a new version of osh, making it less of a command-line utility, and more of a shell. What do you think would be the main properties of a "more modern shell"? Do you think it is OK if this shell drags in a Python interpreter?

madmulita 8y ago

font-weight: 300; Why do they insist on making the text hard to read?

ChicagoDave 8y ago

I worked at a client that manually pulled data from 70+ remote servers every morning to combine into a financial report. I enabled ps-remoting, wrote a bunch of scripts, and turned this process into an automated batch job that took 3 minutes. One of those odd jobs that was a lot of fun.

equalunique 8y ago

I can appreciate the clear explanation of Powershell Remoting in this guide. It was a big part of one of my previous jobs. It is a pathway to basic dev-ops things in a Windows environment.