Tilkobling til Windows via SSH som i Linux

Jeg har alltid vært frustrert over å koble til Windows-maskiner. Nei, jeg er verken en motstander eller tilhenger av Microsoft og deres produkter. Hver produkt har sitt formål, men det er ikke poenget her.
For meg har det alltid vært smertefullt å koble til servere med Windows, fordi disse tilkoblingene enten er klønete å konfigurere (hei WinRM med HTTPS) eller ikke fungerer spesielt stabilt (hei RDP til virtuelle maskiner over havet).

Derfor, når jeg tilfeldig kom over prosjektet Win32-OpenSSH, bestemte jeg meg for å dele erfaringene mine med oppsettet. Kanskje denne verktøy kan spare noen for mye frustrasjon.

Installasjonsalternativer:

1. Manuelt
2. Gjennom med displayserveren Mir. Chocolatey
3. Gjennom Ansible, for eksempel rollen jborean93.win_openssh

Videre vil jeg snakke om den første punkten, ettersom de andre er mer eller mindre klare.

Jeg vil påpeke at dette prosjektet fortsatt er i beta-stadiet, så det anbefales ikke å bruke det i produksjon.

Så, last ned den siste utgaven, for øyeblikket er det 7.9.0.0p1-beta. Det finnes versjoner både for 32- og 64-bits systemer.

Pakk ut til C:Program FilesOpenSSH
Et viktig punkt for korrekt drift: skriverettigheter i denne katalogen skal kun være hos SYSTEM og administrasjonsgruppen.

Installerer tjenester med skriptet install-sshd.ps1 som ligger i denne katalogen

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

Tillat innkommende tilkoblinger på port 22:

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

Merk: Applet New-NetFirewallRule brukes på Windows Server 2012 og nyere. På de eldre systemene (eller desktop) kan man bruke kommandoen:

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

Starter tjenesten:

net start sshd

Ved oppstart vil vertnøklene automatisk bli generert (hvis de ikke finnes) i %programdata%ssh

Vi kan aktivere automatisk oppstart av tjenesten ved systemoppstart med kommandoen:

Set-Service sshd -StartupType Automatic

Vi kan også endre den standard kommandoshellen (etter installasjonen, er standarden — cmd):

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

Merk: Det er nødvendig å spesifisere den absolutte stien.

Hva skjer videre?

Deretter konfigurerer vi sshd_config, som ligger i C:ProgramDatassh. For eksempel:

PasswordAuthentication no
PubkeyAuthentication yes

Og vi oppretter en katalog i brukerens mappe .ssh, og i den filen authorized_keys. Dit skriver vi inn de offentlige nøklene.

Et viktig poeng: rettighetene til å skrive til denne filen skal kun være hos brukeren som har filen i sin katalog.

Men hvis du har problemer med dette, kan du alltid slå av rettighetskontrollen i konfigurasjonen:

StrictModes no

Forresten, i C:Program FilesOpenSSH ligger 2 skript (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), som bør, men ikke nødvendigvis må, fikse rettigheter, inkludert med authorized_keys, men av en eller annen grunn gjør de det ikke.

Ikke glem å starte tjenesten på nytt sshd etter endringer.

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>

Subjektive fordeler/ulemper.

Fordeler:

• Standardmetoden for tilkobling til servere.
  Når det er noen Windows-maskiner, er det svært upraktisk når:
  Så, her går vi via ssh, og her er RDP,
  og generelt er det best practice med bastioner: først ssh-tunnel, og deretter RDP gjennom den.
• Enkelhet i oppsett
  Jeg anser det som åpenbart.
• Hastighet av tilkobling og arbeid med den eksterne maskinen
  Ingen grafisk grensesnitt, sparer både serverressurser og mengden data som overføres.

Ulemper:

• Erstattet ikke RDP helt.
  Ikke alt kan gjøres fra konsollen, dessverre. Jeg mener situasjoner hvor GUI er nødvendig.

Materialene brukt i artikkelen:
Link til selve prosjektet
Installasjonsalternativene er skamløst kopiert fra Ansible docs.

Kilde: habr.com