PowerShell Remoting

https://www.sconstantinou.com/powershell-remoting/

by axiomdata316 • 8 years ago

80 58 8 years ago

tyingq2• 8 years 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.

13of403• 8 years ago

It's not plain text. The traffic is still encrypted by winrm.

tyingq2• 8 years ago

Ahh. Would be a good note in that area of the article.

jodrellblank2• 8 years 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/...

"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/...

userbinator2• 8 years 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.

Jaruzel• 8 years ago

I totally agree here. Every time Microsoft roll out a new product or feature, it seems they go out of their way to make it as complex as possible.

A lot of their server side products have weird restrictions or integrate with their other products in strange ways. Nothing is standardised, or simple.

For example, I'm in the middle of a project that needs to log audit data from a front-end service. The service isn't that busy, so doesn't really log that much, however the reporting interface only works with System Center. So to build out the reporting infrastructure I need: 2x System Center Service Manager Management Servers, and 2x System Center Service Manager Data Warehouse Servers, and 2x SQL Servers in a live-sync arrangement. That's six servers, three in each Datacenter. Four of which need 16Gb of RAM. The Management Servers do hardly any work, but due to an artificial restriction placed in the installer, you cannot install them on the same boxes as the Data Warehouse component. Even if you could, MS wouldn't support it.

All this to log no more than 100-200 events a day. To do the reporting any other way, is unsupported. It's nuts. I am starting to believe that Microsoft are now deliberately making their products so complex and so expensive to build on premises, in order to push customers into their Cloud platforms instead. This is certainly true of Exchange Server which is now an absolute nightmare to manage on premises. It's a mail server, why is it so complex?!

To be honest, it wouldn't surprise me if even internal Microsoft product designers and engineers no longer understand how most of the Microsoft server products even work or integrate.

And I say all this as someone who's spent 25 years working with Microsoft products as my day job.

amaccuish3• 8 years ago

Tbf, using kerberos which most windows installations get for free with AD is a good idea, saves issuing certs etc. But they really need to move on and deprecate NTLM, and basic should only be allowed over TLS... I think you're right with the whole microsoft really does let you shoot youself in the foot, and will gladly hand you the gun to do so.

reificator5• 8 years 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/wind...

13of403• 8 years 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.

reificator5• 8 years 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.

cryptonector• 8 years ago

OTOH there is no online streaming, right?

hobs2• 8 years 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_• 8 years 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.

equalunique2• 8 years 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• 8 years ago

Pywinrm is your friend if you are a nix person.

reificator5• 8 years ago

That's a good tip, I'll check that out. Still hoping for SSH server support though...

xenophonf2• 8 years 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.

newman3142• 8 years 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• 8 years 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• 8 years 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...

nunez• 8 years 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...

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

userbinator2• 8 years 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/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• 8 years ago

For the curious, https://en.wikipedia.org/wiki/Distributed_Computing_Environm...

It sounds super complex to setup.

H1Supreme• 8 years ago

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.

davvolun2• 8 years ago

Considering the relative age of WSL integration in comparison to Windows and Linux themselves, it's progressing very nicely. I feel almost as comfortable on Windows now as I did on OS X 10 years ago -- but I don't need to pay the Mac Tax.

ams6110• 8 years ago

I was doing remote logins to Windows servers over SSH using cygwin like 10 years ago.

amaccuish3• 8 years ago

Yes, and it's was an awful hack and provided an incredibly poor experience. Luckily things are changing with https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...

cm21873• 8 years ago

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.

zaat2• 8 years ago

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.

This isn't even remotely related to PowerShell (no pun intended), it's a security based decision of the windows update API. You can say that it is annoying, stupid and cause of hacks that are much less secure than opening remote operations to the API, and I will agree with you. But it isn't PowerShell business.

As as side note If you are using SCCM you can use WMI for windows update.

PowerShell is far from being half baked, it is a first class citizen in Windows, all the OS GUI tools today executes operations through PowerShell. Many let you see the commands so you can bypass the gui next time and run the commands yourself. As a matter of fact, many things these days can only be done by the shell, while the GUI only expose limited set of the available API.

radicalbyte• 8 years ago

Most of the issues I had with powershell remoting were related to the security model. It's totally integrated into AD. Which is fine if you're in the domain, but a nightmare to manage when you're not. Or if you want to do anything cross-domain (because, you know, you might now want to combine a production and test domain, or have any kind of explicit trust relationship).

AnIdiotOnTheNet• 8 years ago

As a fan and frequent user of PowerShell, I'm afraid I have to agree that PS remoting is pretty clunky. I often end up using psexec with cmd instead.

sametmax• 8 years ago

Not irrelevant: reactivity when typing in a remote shell affects very important features such as completion or resizing.

geophile2• 8 years ago

Along the same lines: 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• 8 years ago

I casually follow the development of the Elvish shell, which uses structured data, and is written in Go:

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.

geophile2• 8 years 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• 8 years ago

font-weight: 300;

Why do they insist on making the text hard to read?

ChicagoDave• 8 years 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.

equalunique2• 8 years 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.

PowerShell Remoting

Related Stories