I’m thrilled to share that a Beta OpenSSH client and server daemon are available as a Feature-on-Demand in Windows 10 Fall Creators Update and Windows Server 1709. Since our last update blog, we’ve been working hard on a Win32 port of OpenSSH and working closely with members of the OpenSSH Portable and OpenBSD projects with the eventual goal of bringing Win32 support upstream into OpenSSH Portable.

Until then, you should expect OpenSSH support in Windows to continue to improve in future updates of Windows, including upcoming Windows Insider builds. You can track our progress on GitHub where you can find our wiki and the latest builds that include tons of fixes and support for operating systems downlevel to Windows 7 and Server 2008 R2.

Overview

OpenSSH is a collection of client/server utilities that enable secure remote login, remote file transfer, and public/private key pair management. It’s an extremely powerful tool that originated as part of the OpenBSD project, and has been used for many years across the BSD, Linux, macOS, and Unix ecosystems.

Note: The OpenSSH client and server are still very much in Beta,so we do not recommend using them in production environments.

Installation

Great! So how do I install the bits?

Installing with the Settings UI

To install it using the Settings UI, go to Apps -> Apps and Features -> Manage optional features -> Add a feature:

Your private key files are the equivalent of a password. You should protect them under any and all circumstances. If someone acquires your private key, they can log in to any SSH server as an identity that authorizes the corresponding public key to log in.

For that reason, we should take advantage of ssh-agent to securely store the private keys within a Windows security context. To do that, we simply start the ssh-agent service (as Administrator) and use ssh-add to store our private key. Then, whenever a private key is needed for authentication, ssh-agent will automatically retrieve your local user’s private key and pass it to your SSH client.

# Make sure you're running as an AdministratorStart-Service ssh-agent
# This should return a status of RunningGet-Service ssh-agent
# Now load your key files into ssh-agent
ssh-add ~\.ssh\id_ed25519
# Now that it's loaded into ssh-agent,# we don't have to keep the key file anymoreRemove-Item ~\.ssh\id_ed25519

Move the contents of your public key (~\.ssh\id_ed25519.pub) into a text file called authorized_keys in ~\.ssh\ on your server/host.

Note: these directions assume your sshd server is a Windows-based machine using our OpenSSH-based server, and that you’ve properly configured it based on the instructions below (including the installation of the OpenSSHUtils PowerShell module). If you’re using a non-Windows machine, you should replace all remote instances of C:\users\user1 with something like /home/user1. Additionally, the ACL line should be unnecessary that uses PowerShell should be unnecessary.

Due to certain security requirements, you will also have to install our OpenSSHUtils helper module to appropriately ACL your host keys. As an Administrator:

Install-Module-Force OpenSSHUtils
Repair-SshdHostKeyPermission-FilePath C:\Windows\System32\OpenSSH\ssh_host_ed25519_key
# Use A or Y as your response to the prompts to set file owners

Then you can start sshd and your server is ready to go:

Start-Service sshd
# This should return a Status of RunningGet-Service sshd

Note: currently only the built-in ED25519 authentication key type is supported. In the future, we plan to add support for LibreSSL which will enable additional authentication key types. In the meantime, you can experiment with LibreSSL builds on GitHub.

You may also need to add a firewall rule like this one that allows traffic on port 22 (though your requirements may vary based on your environment, e.g. Domain might be Private):

Yup! It may just be that your PATH didn’t get updated on non-elevated sessions. Sometimes restarting explorer.exe does it for me, other times I need to reboot. On a per-session basis, you should just be able to run this:

In regard to setting up the SSH server, I had to manually add the “Replace a process level token” privilege to the NT Service\sshd user in order for the sshd service to start. Was that supposed to happen automatically? I tried rebooting after following the above steps, but it didn’t make a difference.

> Note: currently only the built-in ED25519 authentication key type is supported. In the future, we plan to add support for LibreSSL which will enable additional authentication key types. In the meantime, you can experiment with LibreSSL builds on GitHub.

I’ve switched from Linux to Windows because of the Linux Subsystem feature. When will Microsoft roll out the stable release of OpenSSH client and server? Is the current release of openssh safe to use on a laptop which is connected to the internet most of the time?

On Windows 10, I was able to get the sshd service to start when I explicitly granted the “Replace a process level token” privilege (SeAssignPrimaryTokenPrivilege) to the “NT Service\sshd” identity in the local GPO. This is the only required priv listed in the registry for the sshd service.

Also, if you’re experimenting with other user accounts, see the new ‘SSH Users’ group too.

Just installed OpenSSH beta on Windows 10 VM – wanted to use it for SSH based remoting with PowerShell v6. OpenSSH is installed in C:\Windows\System32 which makes configuration changes – i.e. adding the subsystem so OpenSSH can find pwsh.exe very difficult at best and impossible at worst.

I’m backing out the install and will re-install with the rather messy install using the github download.

It comes down to the permissions set on the config file because its in C:\windows\System32. Editing any file in C:\windows\* is problematic at best on the later Windows systems. The drive to Windows doing more for the users to protect people who don’t know what they’re doing makes life difficult for people who do know what should be changed

If the host is a Windows machine where you’re using the release outlined here, then you need to follow the instructions above to generate and configure host keys.

If you don’t own the host, you need it to have ED25519-based host keys (unless you use our latest LibreSSL-based client from GitHub):

> Note: currently only the built-in ED25519 authentication key type is supported. In the future, we plan to add support for LibreSSL which will enable additional authentication key types. In the meantime, you can experiment with LibreSSL builds on GitHub.

Where should we log issues? This version is not working as a client. I did have the GitHub PowerShell/Win32-OpenSSH version installed before and it worked. I did remove that version before installing, this. I would like to log the various issues that I am seeing.

Very cool! Do you have a pointer for me how to add legacy host key algorithms to c:\users\user\.ssh\config so that OpenSSH for Windows allows me to connect to older hosts? I tried:
Host xyz
HostName xyz.domain.com
HostKeyAlgorithms ssh-rsa rsa-sha2-512 rsa-sha2-256
but I get back “Bad key types ‘ssh-rsa’.” from OpenSSH.

> Note: currently only the built-in ED25519 authentication key type is supported. In the future, we plan to add support for LibreSSL which will enable additional authentication key types. In the meantime, you can experiment with LibreSSL builds on GitHub.

Thx for the nice article but what can you do when it is does not show up?
I’m running the windows 10 enterprise 1709 …. but openssh doesn’t show up (it is not available for installation).
Version: 10.0.1439

None of the methods above do work as, openssh is not shown as being available.
I tried tools like “sfc /scannow” or “DISM /Online /Cleanup-Image /CheckHealth” but I didn’t get any errors or warnings. So I assume everything is ok with the OS.

Hi thx for replying.
Let me adjust my first post, and be more specific.
Here is the output of the windows version I’m using:
PS C:\Windows\system32> $PSVersionTable.BuildVersion.ToString()
10.0.16299.15

You need to follow the directions to above to generate host keys, install OpenSSHUtils, and run Repair-SshdHostKeyPermission on the generated host keys. Until you do that, sshd will refuse start, and without it running, you can’t make a connection.

Scenario: Windows 10 1709 Hyper-V VM, with openssh client installed, trying to connect to another Hyper-V VM, server 1709, with openSSH Server installed. Both are in a workgroup, on a Windows 10 1709 host. Connection by password based authentication does not seem to work, is it not supposed to? I keep getting an error that I cannot connect from WIN10 client to Server 1709 due to port 22 connection refused (firewall is turned off on both VMs). Connection using Project Honolulu works fine in this scenario. Wondering what I am doing wrong if it appears to be easy according to this blog.