These days I’m beginning to feel like venerable curmudgeon Andy Rooney. Many of you probably have no idea who that is. Ask your parents. I guess I’ve been in IT long enough that I’m losing patience with a lot of what I consider nonsense, or to borrow a phrase from my pal Will Shakespeare, “much ado about nothing.” My cranky rant today is in some ways a continuation of a previous article I wrote about the benefits or necessity of managing servers with PowerShell instead of a full GUI. If you really want to get me started, then lament the fact that Windows 10 still doesn’t have secure shell (SSH) or some variation on that theme. Barnacles.
When I hear this, all I can think is that the person making the statement is either merely trying to be contrary or is already pre-disposed to be anti-Microsoft or anti-Windows, and they are simply looking for an excuse. True, Windows does not ship out of the box with SSH as most people would define the technology. But to borrow a phrase, “SSH! We don’t need no stinking SSH,” we don’t need an SSH implementation because Microsoft ships PowerShell out of the box, and its remoting feature is the new SSH as far as I am concerned.
At its core, SSH is a mechanism where you can establish a secure, interactive console session on a remote computer. That is exactly what PowerShell remoting is all about. Microsoft uses the WSMan protocol, which is an industry standard. Nothing propriety here like the “old” Microsoft. The protocol is managed by the WinRM service. “But it’s not secure!” I hear people cry. Bollocks.
In a Windows domain environment, where you are most likely going to use remoting, the two end points use Kerberos for mutual authentication. No passwords are ever sent across the wire in plain text. All of the traffic between the two sessions is also encrypted by default over port 5985. At Ignite I was chatting with someone about PowerShell and somehow the topic turned to remoting. He told me they were going all out with PowerShell remoting. They had even run Wireshark traces of remoting sessions to prove to themselves that the traffic was secure. In addition, you can even take remoting to another level and secure the connection with SSL. Now the already encrypted traffic is wrapped again in SSL encryption. If you hear someone say PowerShell remoting isn’t secure, they plainly don’t know what they are talking about and have not taken the time to educate themselves.
PowerShell remoting can be configured for the enterprise with a few Group Policy settings and once you start deploying Windows Server 2012 R2, it is turned on by default. With PowerShell remoting, I can initiate an SSH-like interactive session with a single computer. I can run any console or PowerShell command remotely and securely just as if I were at the physical console. Or I can run the same command on 100 remote computers simultaneously — all secure, encrypted and authenticated.
At the 2015 PowerShell Summit in Charlotte, I demonstrated a delegated management tool that utilized a GUI. The tool and GUI ran on user’s desktop and connected on the backend to a server using PowerShell remoting. In fact, I was connected to a constrained endpoint that could only run a few pre-determined commands with specific parameters. I’d say in this case, if I had been limited to SSH I would have had a less secure tool.
The last point I want to make is that PowerShell remoting is already extending beyond Windows. When combined with the CIM standards, Microsoft is giving IT pros the tools to securely manage non-Windows platforms and devices like network switches. I am excited to see where all of this ends up.
So can we finally stop with the nonsense that PowerShell remoting is no good, not safe, or not SSH? That argument was shaky a few years ago and is downright annoying today. That said, I like to think I am an open-minded curmudgeon. If there is some aspect of SSH that you feel is lacking in PowerShell remoting or some SSH usage scenario I might be overlooking, then please share your thoughts in the comments.