Connecting to Windows via SSH like in Linux

I've always found it frustrating to connect to Windows machines. No, I'm not against Microsoft or their products. Every product exists for its purpose, but that's not the issue here.
I have always dreadfully struggled to connect to Windows servers because these connections are either configured in the most convoluted way (hello WinRM with HTTPS) or are not very stable (hello RDP to virtual machines across the ocean).

Therefore, having accidentally stumbled upon the project Win32-OpenSSH, I decided to share my setup experience. This tool may save someone a lot of nerves.

Installation options:

1. Manually
2. Through the package Chocolatey
3. Via Ansible, for example, the role jborean93.win_openssh

Next, I will discuss the first point, as the others are relatively straightforward.

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

So, let’s download the latest release, which is currently 7.9.0.0p1-beta. There are versions for both 32-bit and 64-bit systems.

Unpack it to C:Program FilesOpenSSH
A crucial moment for proper operation: write permissions in this directory must only be for SYSTEM and the admin group.

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

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

Allow incoming connections on port 22:

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

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

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

Starting the service:

net start sshd

Upon startup, host keys will be automatically generated (if they are missing) in %programdata%ssh

To enable service auto-start with system startup, we can use the command:

Set-Service sshd -StartupType Automatic

Additionally, you can change the default shell (after installation, by default it's cmd):

New-ItemProperty -Path "HKLM:SOFTWAREOpenSSH" -Name DefaultShell -Value "C:WindowsSystem32WindowsPowerShellv1.0powershell.exe" -PropertyType String -Force

Clarification: You must specify the absolute path.

What's next?

Then we adjust sshd_config, located in C:ProgramDatassh. For example:

PasswordAuthentication no
PubkeyAuthentication yes

And create the directory .ssh, and within it, the file authorized_keys. Here, we will write the public keys.

An important clarification: write permissions to this file must be granted only to the user whose directory contains the file.

However, if you have issues with this, you can always disable rights checking in the config:

StrictModes no

By the way, in C:Program FilesOpenSSH there are 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), which are supposed to but not necessarily fix permissions, including those with authorized_keys, but for some reason, they do not fix.

Don't forget to restart the service sshd. after applying the changes.

ru-mbp-666:infrastructure$ ssh Administrator@192.168.1.10 -i ~/.ssh/id_rsa
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:UsersAdministrator> 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:UsersAdministrator>

Subjective pros/cons.

Pros:

• The standard approach to connecting to servers.
  When there are a few Windows machines, it’s quite inconvenient when:
  So, we access this one via ssh, and here it’s RDP,
  and in general, the best practice is with bastions, first an ssh tunnel, and through it RDP.
• Simplicity of configuration
  I think that's obvious.
• Speed of connection and operation with the remote machine
  There is no graphical interface, saving both server resources and the amount of data transmitted.

Cons:

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

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

Source: habr.com