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
The bulk because of soap is sort of irrelevant unless you are in a really slow connection where the size of every packet counts.
I have more serious griefs against powershell remoting.
For instance it is set up as a delayed start service which means you often have to wait more than a minute after a VM rebooted before you can log into it.
Windows Update is accessible by remoting through a COM API that doesn’t allow remote connections, so you can’t do the equivalent of a simple apt-get update remotely. There are horrible hacks around it, like setting up a scheduled task to trigger or collect the update and run that task from remoting and collecting the result some random way like reading a text file.
It really feels half baked, barely usable, and an ugly reminder that CLI has been added to windows as an after thought.
[edit] also I believe it is unencrypted by default. You have to enable https, which isn't straightforward. And you can't change the default ports.
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/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.
I use SSH with the Windows 10 Ubuntu subsystem every day at work. It works great. Aside from the tmux windows frequently needing detached because of graphical glitches (they get "stuck" for lack of a better phrase), I don't have any complaints.
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.
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.
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.
"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."
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.
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.
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.
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.
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...
[+] [-] nunez|7 years ago|reply
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
[+] [-] cm2187|7 years ago|reply
I have more serious griefs against powershell remoting.
For instance it is set up as a delayed start service which means you often have to wait more than a minute after a VM rebooted before you can log into it.
Windows Update is accessible by remoting through a COM API that doesn’t allow remote connections, so you can’t do the equivalent of a simple apt-get update remotely. There are horrible hacks around it, like setting up a scheduled task to trigger or collect the update and run that task from remoting and collecting the result some random way like reading a text file.
It really feels half baked, barely usable, and an ugly reminder that CLI has been added to windows as an after thought.
[edit] also I believe it is unencrypted by default. You have to enable https, which isn't straightforward. And you can't change the default ports.
[+] [-] userbinator|7 years ago|reply
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.
[+] [-] ams6110|7 years ago|reply
[+] [-] H1Supreme|7 years ago|reply
[+] [-] hobs|7 years ago|reply
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_|7 years ago|reply
[+] [-] reificator|7 years ago|reply
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/wind...
[+] [-] 13of40|7 years ago|reply
[+] [-] tyingq|7 years ago|reply
Doesn't seem like a good idea to default to plaintext.
[+] [-] 13of40|7 years ago|reply
[+] [-] jodrellblank|7 years ago|reply
It's encrypted, except when it isn't, except on Tuesdays when it is.
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_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/...
[+] [-] geophile|7 years ago|reply
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: 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|7 years ago|reply
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.
[+] [-] arminiusreturns|7 years ago|reply
[+] [-] reificator|7 years ago|reply
[+] [-] ChicagoDave|7 years ago|reply
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|7 years ago|reply
[+] [-] newman314|7 years ago|reply
Does anyone have any use cases where PS Remoting would be more useful?
[+] [-] nineteen999|7 years ago|reply
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|7 years ago|reply
[+] [-] madmulita|7 years ago|reply
Why do they insist on making the text hard to read?