Connessione a Windows tramite SSH come in Linux

Mi ha sempre frustrato connettermi a macchine Windows. No, non sono un oppositore né un sostenitore di Microsoft e dei loro prodotti. Ogni prodotto esiste per il proprio scopo, ma non è questo il punto.
Per me è sempre stato un grosso dolore connettermi ai server Windows, perché queste connessioni sono configurate in modo macchinoso (salve WinRM con HTTPS) o non funzionano molto bene (ciao a RDP per le VM oltreoceano).

Quindi, casualmente inciampando in un progetto Win32-OpenSSH, ho deciso di condividere la mia esperienza di configurazione. Questa tool potrebbe risparmiare a qualcuno un sacco di nervi.

Opzioni di installazione:

1. Manuale
2. Tramite pacchetto Chocolatey
3. Attraverso Ansible, ad esempio il ruolo jborean93.win_openssh

In seguito parlerò del primo punto, dato che con gli altri le cose sono più o meno già chiare.

Nota che questo progetto è ancora in fase beta, quindi non è consigliato usarlo in produzione.

Quindi, scarichiamo l'ultima versione, attualmente è 7.9.0.0p1-beta. Ci sono versioni per sistemi a 32 e 64 bit.

Decompressiamo in C:\Program Files\OpenSSH
Un aspetto fondamentale per un corretto funzionamento: i diritti di scrittura in questa directory devono essere solo di SYSTEM e del gruppo amministrativo.

Installiamo i servizi tramite script install-sshd.ps1 situato in questa directory

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

Permettiamo le connessioni in ingresso sulla porta 22:

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

Nota: l'applet New-NetFirewallRule è utilizzato su Windows Server 2012 e versioni successive. Nei sistemi più vecchi (o desktop) si può utilizzare il comando:

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

Avviamo il servizio:

net start sshd

All'avvio verranno generati automaticamente le chiavi host (se mancanti) in %programdata%ssh

Possiamo abilitare l'avvio automatico del servizio all'avvio del sistema con il comando:

Set-Service sshd -StartupType Automatic

Inoltre, possiamo cambiare la shell predefinita (dopo l'installazione, di default è cmd):

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

Nota: è necessario specificare il percorso assoluto.

E ora?

E poi configuriamo sshd_config, che si trova in C:ProgramDatassh. Ad esempio:

PasswordAuthentication no
PubkeyAuthentication yes

Creiamo una directory nella cartella dell'utente .ssh, e al suo interno un file authorized_keys. Qui registriamo le chiavi pubbliche.

Un'importante precisazione: solo l'utente nella cui directory si trova il file deve avere i diritti di scrittura su di esso.

Ma se hai problemi con questo, puoi sempre disattivare il controllo dei diritti nella configurazione:

StrictModes no

A proposito, in C:\Program Files\OpenSSH ci sono 2 script (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), che dovrebbero, ma non necessariamente, correggere i diritti, incluso con authorized_keys, ma per qualche motivo non lo fanno.

Non dimenticare di riavviare il servizio sshd dopo per applicare le modifiche.

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

PS C:UsersAdministrator> Get-Host


Nome             : ConsoleHost
Versione          : 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>

Vantaggi/svantaggi soggettivi.

Vantaggi:

• Metodo standard per connettersi ai server.
  Quando ci sono un po' di macchine Windows, diventa molto scomodo quando:
  Quindi, qui andiamo tramite ssh, e qui rdp,
  e in generale la best practice con i bastioni, prima il tunnel SSH, e poi RDP attraverso di esso.
• Semplicità di configurazione
  Ritengo che sia ovvio.
• Velocità di connessione e interazione con la macchina remota
  Nessuna interfaccia grafica, risparmiando sia risorse del server che quantità di dati trasmessi.

Contro:

• Non sostituisce completamente RDP.
  Non tutto è possibile fare dalla console, purtroppo. Parlo di situazioni in cui è richiesta un'interfaccia grafica.

Materiali utilizzati nell'articolo:
Link al progetto vero e proprio
Le varianti di installazione sono state copiate senza vergogna da documentazione Ansible.

Fonte: habr.com