Connessione a Windows tramite SSH come Linux

Sono sempre stato frustrato dalla connessione a macchine Windows. No, non sono né un avversario né un sostenitore di Microsoft e dei suoi prodotti. Ogni prodotto esiste per il proprio scopo, ma non si tratta di questo.
È sempre stato terribilmente doloroso per me connettermi ai server Windows, perché queste connessioni sono configurate attraverso un unico posto (ciao WinRM con HTTPS) o non funzionano in modo molto stabile (ciao RDP alle macchine virtuali all'estero).

Pertanto, essendosi imbattuto accidentalmente nel progetto Win32-OpenSSH, ho deciso di condividere la mia esperienza di configurazione. Forse questo strumento farà risparmiare a qualcuno molti nervi.

Opzioni di installazione:

1. manualmente
2. Attraverso pacchetto cioccolatoso
3. Tramite Ansible, ad esempio role jborean93.win_openssh

Successivamente parlerò del primo punto, poiché con il resto è tutto più o meno chiaro.

Vorrei sottolineare che questo progetto è ancora in fase beta, quindi non è consigliabile utilizzarlo in produzione.

Quindi, scarica l'ultima versione, al momento lo è 7.9.0.0p1-beta. Esistono versioni sia per sistemi a 32 che a 64 bit.

Disimballare C:ProgrammiOpenSSH
Un punto obbligatorio per il corretto funzionamento: solo il SISTEMA e il gruppo di amministrazione.

Installazione di servizi utilizzando uno script install-sshd.ps1 situato in questa directory

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

Consenti connessioni in entrata sulla porta 22:

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

Chiarimento: applet Nuova regola NetFirewall utilizzato su Windows Server 2012 e versioni successive. Nei sistemi più vecchi (o desktop) è possibile utilizzare il comando:

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

Iniziamo il servizio:

net start sshd

All'avvio, le chiavi host verranno generate automaticamente (se mancanti) in %programmadati%ssh

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

Set-Service sshd -StartupType Automatic

È inoltre possibile modificare la shell dei comandi predefinita (dopo l'installazione, l'impostazione predefinita è cmd):

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

Chiarimento: è necessario specificare un percorso assoluto.

Quali sono le prospettive?

E poi lo sistemiamo sshd_config, che inseriremo C: Dati del programma. Ad esempio:

PasswordAuthentication no
PubkeyAuthentication yes

E crea una directory nella cartella dell'utente .ssh, e in esso il file Authorized_keys. Annotiamo lì le chiavi pubbliche.

Chiarimento importante: solo l'utente nella cui directory si trova il file dovrebbe avere il diritto di scrivere su questo file.

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

StrictModes no

A proposito, dentro C:ProgrammiOpenSSH ci sono 2 script (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), che dovrebbero ma non sono obbligati a fissare i diritti, anche con Authorized_keys, ma per qualche motivo non si registrano.

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

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>

Pro/contro soggettivi.

pro:

• Approccio standard alla connessione ai server.
  Quando ci sono poche macchine Windows, è molto scomodo quando:
  Quindi, qui andiamo via ssh, e qui usiamo rdp,
  e in generale, la migliore pratica con i bastioni è prima un tunnel ssh e RDP attraverso di esso.
• Facile da configurare
  Penso che questo sia ovvio.
• Velocità di connessione e lavoro con una macchina remota
  Non esiste una shell grafica, il che consente di risparmiare sia le risorse del server che la quantità di dati trasmessi.

contro:

• Non sostituisce completamente il PSR.
  Non tutto può essere fatto dalla console, ahimè. Intendo situazioni in cui è richiesta una GUI.

Materiali utilizzati nell'articolo:
Link al progetto stesso
Le opzioni di installazione vengono spudoratamente copiate da Documenti Ansible.

Fonte: habr.com