Connessione a Windows tramite SSH proprio come in Linux

Mi ha sempre infastidito connettermi a macchine Windows. No, non sono né un oppositore né un sostenitore di Microsoft e dei loro prodotti. Ogni prodotto esiste per uno scopo specifico, ma non è di questo che si parla.
Per me è sempre stato doloroso connettersi a server Windows, perché queste connessioni vengono configurate in modo complicato (ciao WinRM con HTTPS) oppure non funzionano molto stabilmente (salve RDP per le macchine virtuali oltreoceano).

Quindi, imbattemi casualmente nel progetto Win32-OpenSSH, ho deciso di condividere la mia esperienza di configurazione. Forse a qualcuno questa tool potrebbe far risparmiare un sacco di nervi.

Opzioni di installazione:

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

Ora parlerò del primo punto, poiché con gli altri è tutto più o meno chiaro.

Voglio sottolineare che questo progetto è attualmente in fase beta, quindi non è raccomandato usarlo in produzione.

Dunque, scarichiamo l'ultima release, al momento è 7.9.0.0p1-beta. Ci sono versioni sia per sistemi a 32 che a 64 bit.

Decomprimiamo in C:Program FilesOpenSSH
Un aspetto obbligatorio per il corretto funzionamento: i diritti di scrittura in questa directory devono essere solo per SYSTEM e per il gruppo degli amministratori.

Installa i servizi con lo script install-sshd.ps1 presente in questa directory

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

Consenti le connessioni in entrata 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ò usare 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 generate automaticamente le chiavi host (se assenti) in %programdata%ssh

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

Set-Service sshd -StartupType Automatic

Inoltre, è possibile 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.

Cosa succede dopo?

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

PasswordAuthentication no
PubkeyAuthentication yes

E creiamo nella cartella dell'utente la directory .ssh, e al suo interno il file authorized_keys. Qui inseriamo le chiavi pubbliche.

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

Ma se hai problemi con questo, è sempre possibile disabilitare il controllo dei permessi nel file di configurazione:

StrictModes no

A proposito, in C:Program FilesOpenSSH ci sono 2 script (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), che dovrebbero ma non sono obbligati a correggere i permessi, incluso anche con authorized_keys, ma per qualche motivo non lo fanno.

Non dimenticare di riavviare il servizio Il client SSH e i programmi 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


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>

Pro e contro soggettivi.

Pro:

• Approccio standard per connettersi ai server.
  Quando ci sono alcune macchine Windows, è molto scomodo quando:
  Quindi, qui ci connettiamo tramite ssh, mentre qui tramite rdp,
  e in generale, le best-practice con i bastioni, prima tunnel ssh, e poi tramite quello RDP.
• Semplicità di configurazione
  Ritengo che sia ovvio.
• Velocità di connessione e operatività con la macchina remota
  Nessuna interfaccia grafica, si risparmiano sia le risorse del server che la quantità di dati trasmessi.

Contro:

• Non sostituisce completamente RDP.
  Non tutto può essere fatto dalla console, purtroppo. Parlo di situazioni in cui è necessario un GUI.

Materiali utilizzati nell'articolo:
Link al progetto stesso
Le opzioni di installazione sono state copiate senza vergogna da Ansible docs.

Fonte: habr.com