With the advent of PowerShell v6.0, the PowerShell engine is now available on Windows, macOS, and Linux. Learn the status of Windows–Linux PowerShell remoting.

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

set winrm/config/ServiceDid you get the memo that Microsoft Loves Linux? It's true. In fact, the PowerShell development team open-sourced most of the PowerShell engine at GitHub. As of this writing in mid-March 2017, PowerShell v6.0 for Linux and Mac remains in the alpha development stage.

This means, of course, that is premature to test PowerShell in Linux and expect any complete functionality. Nonetheless, I thought it important for us to "kick the tires" and look into specifically what's possible for Windows-to-Linux and Linux-to-Windows remoting within PowerShell.

Review the Windows environment ^

On the Windows side, I have a fully patched Windows Server 2016 workgroup machine. As you know, Windows Server 2016 and Windows 10 ship with PowerShell v5.1. Here, let me show you my $PSVersionTable results:

Pay particular attention to the new PSEdition property--this gives us a quick sanity check as to which operating system we're attached to. For this tutorial, I decided to stay with PowerShell v5.1 instead of installing the latest alpha release from GitHub.

Install PowerShell on CentOS Linux ^

On the Linux side, I have a fully patched CentOS 7 system with the basic server packages installed. Microsoft has some PowerShell for Linux installation docs; here I'll buzz through the simple workflow for CentOS Linux using their own code:

The first thing we'll want to do after starting PowerShell on Linux is to check our version and PSEdition:

PowerShell remoting architecture ^

As you know, Windows hosts can communicate using Windows Remote Management (WinRM)-based PowerShell remoting sessions. WinRM is an implementation of the Web Services for Management (WS-Man) specification, which in turn takes advantage of firewall-friendly HTTP (TCP port 5985) or HTTPS (TCP port 5986) protocols to establish the communications channel. This channel uses more-or-less "traditional" XML/SOAP web services.

Of course, the WinRM service is Windows-specific, so the PowerShell team has some work to configure the Linux PowerShell engine to do WS-Man remoting. The best I can make out (this situation is murky; I challenge you to read the PowerShell project's issues lists) is that Linux supports WS-Man remoting through a combination of PowerShell Remoting Protocol (MS-PSRP) and an Open Management Infrastructure (OMI) provider. Here is a nice deep-dive into the relationship between WinRM and PSRP.

Whew--we are getting into the high conceptual weeds here! The bottom line is that we need to install both OMI and the OMI provider on our Linux box if we have any hope of accomplishing PowerShell remoting, much less Desired State Configuration (DSC).

If you don't know, OMI is a standard interface for exposing Common Information Model (CIM) data on non-Windows systems. We Windows systems administrators know CIM as the Windows Management Instrumentation (WMI) repository on Windows systems.

We don't have the space to do a step-by-step walkthrough, so your next configuration steps in Linux are to:

  1. Install and configure OMI server
  2. Install the PSRP Linux support library

Now that we've come this far, let's see what's possible.

Windows-to-Linux remoting ^

The first thing I wanted to try was an interactive remoting session from Windows Server 2016 to CentOS Linux. Per the docs, this is what I did, and as you can see from the subsequent screenshot, I was successful:

Windows to Linux PowerShell remoting

Windows to Linux PowerShell remoting

Cross-platform PowerShell remoting uses HTTP authentication methods, specifically either basic access or Windows NT LAN Manager (NTLM). For our purposes, we went with the easier, safer choice while the PowerShell engine is in alpha.

The second thing I wanted to do is to use Invoke-Command to run an ad-hoc scriptblock as well as a .ps1 script.

For this it worked as long as I reused the "hobbled" session configuration options. Remember--PowerShell for Linux and macOS is in alpha state, so we're just testing here.

Invoke-Command -ComputerName 13.85.9.32 -ScriptBlock { Get-Process } ‑Authentication Basic -SessionOption $o -Credential $cred -UseSSL | Select-Object -First 5

Obtaining a process listing from a remote Linux server

Obtaining a process listing from a remote Linux server

I have a simple hello.ps1 script that contains a single Write-Output 'Hello world!' statement. Let's run it from Windows:

That worked! It's important for us to remember that PowerShell on Linux and macOS exists on top of the portable .NET Core runtime and not the full .NET Framework we have in Windows. This means you'll likely need to modify your PowerShell scripts a bit for them to work locally on Linux or macOS. On the other hand, you could use implicit remoting to load remote modules into the local system's runspace.

Linux-to-Windows remoting ^

The PowerShell development team is much further along in Windows-to-Linux PowerShell remoting than it is the other way around. Frankly, there are more moving parts in this approach, especially if you're using NTLM for authentication on the Windows side.

On your Windows test system, you can enable basic authentication and allow unencrypted connections by running the following commands:

And then in Linux we can do this to make an interactive session with the remote Windows server:

The PSRP repository at GitHub briefly explains the above procedure.

Upcoming: secure shell-based remoting ^

From what those who know have told me, PowerShell inventor Jeffrey Snover didn't want to use WS-Man for PowerShell remoting. Instead, his vision of cross-platform PowerShell remoting relied upon the longstanding Secure Shell (SSH) cryptographic network protocol.

In fact, the PowerShell team has been working on their Windows OpenSSH port for a long time, and the repository is still very active. At this point I'd say that the team's PowerShell Remoting Over SSH article is the definitive general overview.

WS-Man and SSH do not represent an "either/or" proposition. You may find that using WS‑Man is appropriate for some situations, and using SSH is appropriate for others. You'll be able to choose them at your convenience!

Win the monthly 4sysops member prize for IT pros

Share
6+

Users who have LIKED this post:

  • avatar
  • avatar

Related Posts

5 Comments
  1. Karim Buzdar 8 months ago

    Well written 🙂

    / Karim

    0

  2. Christoph Loesch 5 months ago

    Linux-to-Windows remoting:

    typo in: winrm set winrm/config/Service @{AllowUnencrypted="true")

    should be: winrm set winrm/config/Service @{AllowUnencrypted="true"}

    great blog post, thanks!

    1+

  3. Hugo van der Kooij 3 months ago

    I needed to use extra quotes:

    0

  4. Hari 2 months ago

    Hi,

    Can I connect to Linux server which is on different network from my laptop via VPN connection?

    Hari

    0

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account