- Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
Let me cite Jeff first:
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.
First of all, I admit that I am pre-disposed. I’ve been accused of being a Microsoft fan boy many times. And the accusations are correct. Nobody is perfect. I also had my fair share of fights with pre-disposed open source advocates. That’s just for the record.
So when I now side with those pre-disposed Linux fan boys who Jeff targets in his article, I feel my heart bleeding. However, I believe Microsoft’s decision to support SSH in future Windows versions is overdue and absolutely necessary.
I think this decision has nothing to do with security, although I do believe that SSH is more secure than PowerShell Remoting. I will address the latter point in a minute. But let me first say why I feel that Windows needs SSH.
Why Windows needs SSH
SSH is an industry standard. It has been around for 20 years, and countless admins around the globe use it daily. This includes me. I suppose this won’t change in the next 20 years or so. Obviously, this decision has to do with the new Microsoft that we are seeing since Nadella took over from Ballmer. The new motto is “if you can’t beat them, join them.” PowerShell Remoting won’t beat SSH because Linux will continue to dominate the cloud in the years to come. Microsoft knows that and even accepts it.
Jeffrey Snover, the PowerShell inventor, recently said in an interview that Azure will become the best cloud provider for Linux. Jeffrey Snover loves Linux, Satya Nadella loves Linux, Microsoft loves Linux. This is as true as the fact that the command line has again become the main interface for managing a Microsoft OS. In the same interview, Snover said, “Make yesterday the last day that you ever hired a click-next admin.” One is inclined to add, make yesterday the last day you ever hired an admin who has no clue about Linux. Let’s wait for the next interview. Don't like Linux? Get over it and get on with it. 😉
From all this follows that Windows badly needs SSH support. Windows and Linux will live in the cloud side by side, and the communication between both operating systems will intensify heavily. This requires a robust, reliable, and secure protocol that is deeply integrated in both operating systems. I can’t imagine that PowerShell Remoting (or WSMan, for that matter) will become a standard in remote Linux management any time soon. SSH is the natural choice. Jeff, this is true whether SSH stinks or not.
Aside from the automated communication between virtual machines in the cloud, SSH support in Windows will serve two other major purposes. It will allow Windows admins to manage Linux machines without the need to rely on hopelessly outdated third-party SSH clients (such as PuTTY) for Windows, and Linux and Mac users will be able to easily connect to Windows machines and manage them with PowerShell. All operating systems are moving closer together, and a common communication protocol is therefore indispensable.
Why SSH is more secure than PowerShell Remoting
It appears some Linux fans think that Windows needs SSH because PowerShell Remoting is insecure and that Jeff somehow feels wound in his honor as one of the major PowerShell gurus out there. I don’t think that Windows needs SSH because of security reasons, and I don’t think that PowerShell Remoting is inherently insecure. However, I do think that SSH is more secure than PowerShell Remoting.
It is true that, by default, PowerShell Remoting encrypts all traffic. That’s good. Not so good is that you can allow unencrypted traffic for backward compatibility. SSH isn’t so generous. It was built because telnet, rlogin, and other remote shells were insecure and, right from the beginning, reducing security because of backward compatibility was out of the question.
However, this is not my main concern. A secure protocol does not only have to encrypt all traffic because encryption only ensures confidentiality. Another important security feature of a communication protocol is authenticity. Actually, without authenticity, the encryption is not worth much because an attacker that sits between the communication parties can intercept the key exchange (man-in-the-middle attack).
PowerShell Remoting is perfectly safe as long as you operate in an Active Directory domain because the trust relationship between domain members takes care of the authentication. But the problems begin as soon as you leave your Windows domain or forest.
For these cases, PowerShell Remoting supports HTTPS. HTTP doesn’t offer an authentication mechanism, but HTTPS does. By default, WSMan, the protocol on which PowerShell Remoting relies, runs over HTTP. This is another security problem of PowerShell Remoting because many admins are not aware of this and use the default configuration in cases where they should switch to HTTPS.
The third problem is that configuring PowerShell Remoting for HTTPS is relatively cumbersome compared to SSH’s public key authentication method. You either need a publicly-signed certificate or you have to create a self-signed certificate and then manually start a WSMan HTTPS listener, manually change Windows Firewall rules, and so on. Even those admins who know how to do this will often avoid jumping through all those hoops if they just want to quickly connect to a non-domain member to run a single PowerShell command. I will explain the procedure in detail in a follow-up post.
Of course, SSH also faces the authenticity problem, but it solves it much more elegantly. Public key authentication is now standard with SSH and usually doesn’t require any extra effort. For instance, when you launch an EC2 Linux instance, Amazon automatically provides the private key. All you have to do is import the key in your SSH client and you are done. The public key is automatically deployed to the Linux machine. Amazon doesn’t even give you a user name and password to log on to Linux. This is how a remote shell is supposed to work in the cloud.
Yes, some cloud providers still work with old-fashioned password authentication. However, even in those cases, SSH is more secure. When you first establish an SSH connection, the SSH client will present the host’s public key fingerprint; if you accept the fingerprint, it will be stored locally. Crucial changes on the host—for example, a new SSH installation or a changed IP address—will generate a new public key and you will then be warned with the new fingerprint.
SSH informs you if the fingerprint has changed
This can prevent man-in-the-middle attacks even without using public key authentication. An attacker has to intercept the communication when you first connect to the remote machine. However, if you use PowerShell Remoting together with mere password authentication over HTTP to standalone machines, you are always vulnerable to man-in-the-middle attacks, and all the nice encryption is not of much help.
Having said that, it is perfectly possible to use PowerShell Remoting securely if you configure it properly. However, when it comes to rating the security of a technology, the technical possibilities are just one discipline. Equally important is how difficult and costly it is to use the security features because, as experience has shown, if security features are too complicated to deploy, people don’t use them either because of ignorance or laziness. I am positive that Microsoft can improve PowerShell Remoting in a future version. Perhaps Microsoft’s SSH team can provide some input here.
If there is some aspect of the security of PowerShell Remoting that you feel I might be overlooking, then please share your thoughts in the comments or post an article on your blog. 🙂
Join the 4sysops PowerShell group!
Your question was not answered? Ask in the PowerShell forum!
This is a very thoughtful article. I will be the first to admit not knowing a great deal of the technical details surrounding SSH. For IT Pros in a mixed shop, which seems to be growing these days, I can readily accept that Microsoft adopting SSH is a good thing. I should point out that I wrote my article before Microsoft made its announcement. If I had written the article a few days later I’m sure it would have had a different tone.
I’ll also agree that implementing PowerShell remoting with SSL is a bit more complicated. In fact, there are still plenty of implementation details that I wish were easier, especially once you get out of a domain environment. But remember that PowerShell remoting is still a relative youngster compared to its open source counterparts.
I still stand behind my original “rant” about Windows admins dismissing PowerShell remoting. Once it is in place it can completely change how we do our jobs. Microsoft adding SSH support will change it even more.
I am all for this because even though powershell remoting in a domain works great for me, I am in a small environment and am just as likely to need to use powershell as I am ssh. I have to connect to network devices on a regular basis, which necessitates a 3rd party program.
Now, since the 3rd party program will save my sessions for those connections, and I am happy with that free program, i am not very likely to use SSH much through windows. But, having it there will be nice, and is long overdue. Just like natively mounting an ISO was long, long overdue.
Jeff, thanks! I somehow thought your article is a reaction to Microsoft’s announcement. I agree that there is no reason to dismiss PowerShell Remoting because it is already more advanced in some aspects. For instance, I love the different ways it supports to receive results from remote sessions and process them.
But what would really be cool is if I could use SSH instead of HTTP or HTTPS to connect to a remote machine via PowerShell Remoting. So when I launch a Nano server in Azure, I just need a private key and I am in.
Daven, you are right, all kinds of non-Windows devices would also be easier to manage. Perhaps Microsoft’s support for SSH will convince some hardware makers to support PowerShell.
The goal is for an IT Pro to manage everything from their desktop using PowerShell, even non-Microsoft and non-Windows devices. I always assumed this would happen through WSMAN, CIM and open source equivalents. But now this may also include SSH.