Verbinding maken met Windows via SSH zoals in Linux

Het heeft me altijd verdrietig gemaakt om verbinding te maken met Windows-machines. Nee, ik ben geen tegenstander of voorstander van Microsoft en hun producten. Elk product heeft zijn eigen doel, maar daar gaat het nu niet om.
Voor mij was het altijd pijnlijk om verbinding te maken met servers met Windows, omdat deze verbindingen ofwel via een vervelende manier worden ingesteld (hallo WinRM met HTTPS) of niet erg stabiel werken (hallo RDP naar virtuele machines over de oceaan).

Dus, toevallig stuitend op het project Win32-OpenSSH, besloot ik mijn ervaring met de configuratie te delen. Misschien bespaart deze tool iemand een hoop zenuwen.

Installatiemogelijkheden:

1. Handmatig
2. Via pakket Chocolatey
3. Via Ansible, bijvoorbeeld de rol jborean93.win_openssh

Daarna zal ik het hebben over het eerste punt, aangezien de andere twee redelijk duidelijk zijn.

Ik merk op dat dit project momenteel in beta-stadium is, daarom wordt het niet aanbevolen om het in productie te gebruiken.

Laten we de laatste release downloaden, momenteel is dat 7.9.0.0p1-beta. Er zijn versies voor zowel 32- als 64-bits systemen.

Pak het uit in C:Program FilesOpenSSH
Een verplicht punt voor een correcte werking: de schrijfrechten in deze directory moeten alleen zijn voor SYSTEM en de beheerdersgroep.

Installeer de services met het script install-sshd.ps1 dat zich in deze directory bevindt

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

Sta binnenkomende verbindingen op poort 22 toe:

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

Opmerking: de applet New-NetFirewallRule wordt gebruikt op Windows Server 2012 en nieuwer. In oudere systemen (of desktopversies) kan de opdracht worden gebruikt:

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

Start de service:

net start sshd

Bij het starten worden automatisch host-sleutels gegenereerd (indien afwezig) in %programdata%ssh

We kunnen de automatische start van de service bij het opstarten van het systeem inschakelen met het commando:

Set-Service sshd -StartupType Automatic

Daarnaast kan de standaard command shell worden gewijzigd (na installatie, standaard is) cmd):

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

Opmerking: het absolute pad moet worden opgegeven.

Wat nu?

En vervolgens configureren we sshd_config, dat zich bevindt in C:ProgramDatassh. Bijvoorbeeld:

PasswordAuthentication no
PubkeyAuthentication yes

En maak in de gebruikersmap de directory .ssh, en daarin het bestand authorized_keys. Daarin schrijven we de publieke sleutels.

Belangrijke opmerking: alleen de gebruiker wiens directory het bestand heeft, moet schrijfrechten op dit bestand hebben.

Maar als je hier problemen mee hebt, kan je altijd de rechtencontrole in de configuratie uitschakelen:

StrictModes no

Overigens, in C:Program FilesOpenSSH er liggen 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), die de rechten zouden moeten fixen, maar dat hoeven ze niet per se te doen, ook met authorized_keys, maar om de een of andere reden fixen ze het niet.

Vergeet niet de service opnieuw te starten sshd na het aanbrengen van de wijzigingen.

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

PS C:UsersAdministrator> Get-Host


Naam             : ConsoleHost
Versie          : 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>

Subjectieve voor- en nadelen.

Voordelen:

• Standaardbenadering voor verbinding met servers.
  Wanneer er een paar Windows-machines zijn, is het erg onhandig wanneer:
  Zo, hier gaan we via ssh, en hier rdp,
  en algemeen is de best-practice met bastions, eerst ssh-tunnel, en daarachter RDP.
• Gemak van configuratie
  Ik vind dat dit voor de hand ligt.
• Snelheid van verbinding en werken met de externe machine
  Er is geen grafische interface, wat bespaart zowel serverbronnen als de hoeveelheid verzonden gegevens.

Nadelen:

• Vervangt RDP niet volledig.
  Niet alles kan vanuit de console worden gedaan, helaas. Ik bedoel situaties waarin een GUI vereist is.

Materialen die in het artikel zijn gebruikt:
Link naar het project zelf
Installatieopties zijn schaamteloos gekopieerd van Ansible docs.

Bron: habr.com