Connecting to Windows via SSH as in Linux

  • Tutorial
I was always depressed by the connection to Windows machines. No, I am not an opponent or supporter of Microsoft and their products. Each product exists for its purpose, but this is not about that.
It has always been painfully painful for me to connect to Windows servers, because these connections are either configured through one place (hello WinRM with HTTPS) or do not work very stably (hello RDP to virtual machines overseas).

Therefore, accidentally stumbled upon a Win32-OpenSSH project , I decided to share the configuration experience. Maybe someone this tool save a bunch of nerves.

Installation Options:

  1. Manually
  2. Via Chocolatey Package
  3. Via Ansible, e.g. role jborean93.win_openssh

Next, I will talk about the first point, as with the rest, and so everything is more or less clear.

I note that this project is still in beta, so it is not recommended for use in production.

So, download the latest release, currently it is . There are versions for both 32 and 64 bit systems.

Unpack it in C: \ Program Files \ OpenSSH
Mandatory moment for correct operation: only SYSTEM and the admin group must have write permissions in this directory .

Install services with the install-sshd.ps1 script located in this directory

powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1

Allow incoming connections to port 22:

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Clarification: the New-NetFirewallRule applet is used on Windows Server 2012 and later. In the oldest systems (or desktop), you can use the command:

netsh advfirewall firewall add rule name=sshd dir=in action=allow protocol=TCP localport=22

We start the service:

net start sshd

At startup, host keys (if absent) in % programdata% \ ssh will be automatically generated.

We can enable the service to start the service at system startup with the command:

Set-Service sshd -StartupType Automatic

Also, you can change the default shell (after installation, the default is cmd ):

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force

Specification: An absolute path must be specified.

What's next?

And then configure sshd_config , which we will place in C: \ ProgramData \ ssh . For instance:

PasswordAuthentication no
PubkeyAuthentication yes

And create the .ssh directory in the user folder , and in it the authorized_keys file . We write public keys there.

An important clarification: only the user in whose directory the file is located must have write permissions to this file.

But if you have problems with this, you can always turn off rights checking in the config:

StrictModes no

By the way, in C: \ Program Files \ OpenSSH there are 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), which should but are not required to fix the rights, including with authorized_keys , but for some reason they will not be fixed.

Remember to restart the sshd service after to apply the changes.

ru-mbp-666:infrastructure$ ssh Administrator@ -i ~/.ssh/id_rsa
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Users\Administrator> Get-Host
Name             : ConsoleHost
Version          : 5.1.14393.2791
InstanceId       : 653210bd-6f58-445e-80a0-66f66666f6f6
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace
PS C:\Users\Administrator>

Subjective pros / cons.


  • A standard approach to connecting to servers.
    When there are few Windows machines, it’s very inconvenient when:
    So, we go here via ssh, and here rdp,
    and generally best-practice with bastions, first an ssh tunnel, and through it RDP.
  • Easy setup.
    I think this is obvious.
  • The speed of connecting and working with a remote machine
    There is no graphical shell, both server resources and the amount of data transferred are saved.


  • Does not replace RDP completely.
    Not everything can be done from the console, alas. I mean situations where a GUI is required.

Materials used in the article:
Link to the project itself.
Installation options unscrupulously copied from Ansible docs .

Also popular now: