- 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
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 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. 🙂