ProHoster > Blog > Administration > Connecting to Windows via SSH as in Linux

Connecting to Windows via SSH as in Linux

I've always been frustrated with connecting to Windows machines. No, I am not an opponent or supporter of Microsoft and their products. Each product exists for its own purpose, but that's not the point.
It has always been excruciatingly painful for me to connect to Windows servers, because these connections are either configured through one place (hello WinRM with HTTPS) or work not very stable (hello RDP to virtual machines overseas).

Therefore, accidentally bumping into the project Win32-OpenSSH, I decided to share my setup experience. Perhaps this tool will save someone a lot of nerves.

Connecting to Windows via SSH as in Linux

Installation options:

  1. Manually
  2. Through package Chocolate and
  3. Through Ansible, for example a role jborean93.win_openssh

Further, I will talk about the first point, since with the rest, everything is more or less clear.

I note that this project is still at the beta stage, so it is not recommended to use it in production.

So, download the latest release, at the moment it is 7.9.0.0p1-beta. There are versions for both 32 and 64 bit systems.

Unpacking in C:Program FilesOpenSSH
Mandatory moment for correct operation: only the SYSTEM and the admin group.

Installing services with a 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

Specification: applet New-NetFirewallRule used on Windows Server 2012 and newer. In the oldest systems (or desktop ones), 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

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

We can enable autostart of the service at system startup with the command:

Set-Service sshd -StartupType Automatic

Also, you can change the default command shell (after installation, by default - cmd):

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

Clarification: You must specify an absolute path.

What's next?

And then we set up sshd_config, which is located in C:Program Data. For example:

PasswordAuthentication no
PubkeyAuthentication yes

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

Important clarification: only the user in whose directory the file is located should have write permissions to this file.

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

StrictModes no

By the way, in C:Program FilesOpenSSH 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 don't fix it.

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

ru-mbp-666:infrastructure$ ssh [email protected] -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:

  • Standard approach to connecting to servers.
    When there are few Windows machines, it is very inconvenient when:
    So, here we go via ssh, and here rdp,
    and generally best-practice with bastions, first an ssh tunnel, and through it RDP.
  • Easy to set up
    I think it's obvious.
  • Speed ​​of connection and work with a remote machine
    There is no graphical shell, both server resources and the amount of transmitted data are saved.

Cons:

  • Does not completely replace RDP.
    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 shamelessly copied from Ansible docs.

Source: habr.com

Add a comment