OpenSSH Doesn’t Replace PowerShell Remoting in Fall Creators Update

The Windows 10 Fall Creators Update and Windows Server 1709 include a beta OpenSSH server and client. In this Ask the Admin, I’ll discuss how OpenSSH differs from PowerShell Remoting.

Microsoft has been working to port OpenSSH to Windows over the last couple of users and in the Fall Creators Update, you can try it out in beta. But just because Microsoft is adding an OpenSSH client and server to Windows, doesn’t mean that you should ditch PowerShell Remoting in favor of SSH.

PowerShell Remoting Versus OpenSSH

While Microsoft hasn’t made an official statement about why it’s adding SSH to Windows, there are some scenarios where using SSH might be a requirement or a better option than the existing remoting tools. Management systems that were built for Linux, like Ansible, use SSH as the default method of connecting to remote servers. Although, Ansible version 1.7 did add support for PowerShell Remoting. But nevertheless, it would be useful if Windows had a built-in SSH server in these scenarios. More mature configuration management solutions, like Puppet, use a client/server model and don’t rely on the server accepting an SSH connection. But unlike Ansible, Puppet requires an agent on each managed endpoint.

Probably more interesting though is that Microsoft’s OpenSSH implementation will include a client. For Windows administrators, that’s not likely to be very exciting but for those who need to manage Linux, having a built-in SSH client is obviously useful.

It’s worth understanding that PowerShell Remoting, which is based on an open SOAP-based protocol called WS-Management, is fundamentally different from SSH. SSH functions like a remote terminal. When you type in the terminal window, the characters are sent as a text stream to the remote system and then echoed back to you in the terminal window. Linux is managed using text configuration files, so this method of sending text streams suits Linux management well.

Windows uses a set of management APIs, which expects to receive structured data in the form of objects. This is not a text stream that then has to be analyzed to find the information it needs. When you type commands to a remote device using PowerShell Remoting, the console waits until you hit ENTER, sends the commands to the remote device, serializes the results into XML, and then sends them back to your console, which deserializes them so that you can read them. This system works better for sending chunks of structured data.

Managing Standalone Systems

There’s one situation where administrators might prefer to use SSH over Remoting. When PowerShell Remoting is used between two devices that are joined to the same Active Directory domain, server authentication and encryption are performed without any additional steps required from the user. But when connecting to a standalone system, PowerShell Remoting should be used with HTTPS. However, this can be tricky to set up because either you need to configure self-signed certificates on both the client and server, which is not recommended or set up a public key infrastructure (PKI).

In situations where you need to connect to a standalone remote endpoint, SSH is more convenient. Public/private key pair management is easier to set up than a PKI. Additionally, public/private key pairs can be more convenient in automation tasks because you don’t have to manage usernames and passwords. When you generate a key pair using ssh-keygen, two files are created, the public key (.pub) and the private key. The private key acts like a password and should be protected at all times. The public key is moved to the server and the private key is used on clients to connect securely to the server. The Windows ssh-agent agent service can be used to store private keys securely.

If you’d like to set up the OpenSSH beta in Windows, Microsoft has detailed instructions on its website here. We have also a detailed guide on how to install and configure OpenSSH on Windows.