I’m doing a talk at MVPDAYS on Open Source PowerShell and one of the items I was most excited about I had to try… PowerShell remoting!
In the current release it’s still an interactive PowerShell session but it’s amazing what it will bring forth. The option for a Windows Admin to remote to a Linux/macOS system with a PowerShell script from Windows! Or simply to consume the text data from Linux and flip it to objects. Natively converting Json and XML!
Or for the Linux admin stuck with some Windows Servers. It means running your native Bash, firing up a PowerShell command to manage those Windows Servers the Business brought in… or in the long term using Cmdlets provided by Vendors like Dell to manage applicances…
It’s all about OPTIONS for the Admin.
But today I REALLY wanted to play with PowerShell remoting. Jason Helmick showed it online with Jeffrey Snover and it really IS is. Requirements are pretty simple too.
- Open Source PowerShell at both endpoints
- OpenSSH on a Linux / macOS
- SSH_Win32 on Windows
- Some minor configuration
And use is just as easy.
New-Pssession –hostname ComputerwithSSHServer –username whoeveryouare
After a password prompt you just connect and you’re in the OTHER side using PowerShell!
I had everything loaded up, the most current release of PowerShell from Github on Windows and Linux, Open SSH, followed the instructions to the letter and
Windows would not receive the open connection Linux with some weird cryptic error. Linux could not receive from Windows.
Jason suggested the first thing which was “confirm SSH” works. Which I did. Pretty easy test too
I poked about online and saw a reference from Microsoft regarding a bug in which the SSH_Win32 would drop a blank line with a successful connection in STDERR . Since it was a recent bug and Jason had demoed the Open Source PowerShell with PSRemoting maybe a tad early than that… I guessed there might have been a bug somewhere about.
So stage one. Rollback to PowerShell 18.104.22.168 and one version EARLIER of SSH_Win32.
Once I did THAT Linux happily connected to Windows via PowerShell Remoting!
(yeah there’s always a But somewhere)
Windows still could not initiate the session. Evil vile cryptic error message about he Endpoint having finished already. However in running through the troubleshooting (Running the SSHD in Diagnostic mode) I could see the connection didn’t FAIL it just NEVER ACTUALLY HAPPENED.
“That’s it! Pull out the big guns! Mark Russinovich will LOVE THIS! We’re going to use a Sysinternals tool to fix a buggy feature in PowerShell 6!”
Procmon.exe was downloaded. I set it to only watch powershell.exe for events. Cleared off the old events of course.
Started the New-Pssession –hostname eotubuntu –username energizedtech
Watched the fail
Get rid of all the successes on the filter
Drilling back the most recent set of entries I noticed a search through various folders for SSH.EXE and GET-SSH.EXE. Including an interesting one.
‘C:\Program Files (x86)\Putty’
But I never had Putty on this server! It was a clean Server 2016 RTM. Which told me…. (no no wait… looks like I did!)
Here’s the list it found
But on Server 2016 it CLEARLY showed C:\Program Files\OpenSSH in the system path…. which was wrong.
It should ACTUALLY have been C:\Program Files\OpenSSH\ (Notice that extract Backslash? I DIDN’T)
So I re-edited the path to hold it and now it all works properly.
Why was it missing the Backslash? I used the new “Browse for Path” feature in the Path Editor of Server 2016. It did it. Must be an undocumented feature.
With that change in place I could happily run PowerShell remoting from Windows to Linux or Linux back to Windows
….Can’t WAIT for Implicit Remoting !