Conexión a Windows a través de SSH como en Linux

Siempre me deprimió la conexión a las máquinas con Windows. No, no soy oponente ni partidario de Microsoft y sus productos. Cada producto existe para su propósito, pero no se trata de eso.
Siempre me ha resultado dolorosamente doloroso conectarme a los servidores de Windows, porque estas conexiones están configuradas a través de un solo lugar (hola WinRM con HTTPS) o no funcionan de manera muy estable (hola RDP para máquinas virtuales en el extranjero).

Por lo tanto, accidentalmente me topé con un proyecto Win32-OpenSSH , decidí compartir la experiencia de configuración. Quizás alguien esta herramienta salve un montón de nervios.



Opciones de instalacion:

1. Manualmente
2. Via Paquete Chocolatey
3. Vía Ansible, por ejemplo, rol jborean93.win_openssh

A continuación, hablaré sobre el primer punto, como con el resto, y así todo está más o menos claro.

Observo que este proyecto todavía está en beta, por lo que no se recomienda su uso en producción.

Entonces, descargue la última versión, actualmente es 7.9.0.0p1-beta . Hay versiones para sistemas de 32 y 64 bits.

Descomprimir en C: \ Archivos de programa \ OpenSSH
Momento obligatorio para el trabajo correcto: solo SYSTEM y el grupo de administración deben tener permisos de escritura en este directorio.

Instale servicios con el script install-sshd.ps1 ubicado en este directorio

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

Permitir conexiones entrantes al puerto 22:

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

Aclaración: el applet New-NetFirewallRule se usa en Windows Server 2012 y versiones posteriores. En los sistemas más antiguos (o escritorio), puede usar el comando:

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

Iniciamos el servicio:

 net start sshd 

Al inicio, las claves de host (si faltan) se generarán automáticamente en % programdata% \ ssh

Inicio automático del servicio al inicio del sistema que podemos habilitar con el comando:

 Set-Service sshd -StartupType Automatic 

Además, puede cambiar el shell predeterminado (después de la instalación, el valor predeterminado es cmd ):

 New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force 

Especificación: se debe especificar una ruta absoluta.

Que sigue

Y luego configure sshd_config , que colocaremos en C: \ ProgramData \ ssh . Por ejemplo:

 PasswordAuthentication no PubkeyAuthentication yes 

Y cree el directorio .ssh en la carpeta del usuario, y en él el archivo autorizado_claves . Escribimos claves públicas allí.

Una aclaración importante: solo el usuario en cuyo directorio se encuentra el archivo debe tener permisos de escritura en este archivo.

Pero si tiene problemas con esto, siempre puede desactivar la verificación de derechos en la configuración:

 StrictModes no 

Por cierto, en C: \ Archivos de programa \ OpenSSH hay 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), que deberían pero no están obligados a corregir los derechos, incluso con autorizadas_keys , pero por alguna razón no se corregirán.

Recuerde reiniciar el servicio sshd luego de aplicar los cambios.

 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:\Users\Administrator> 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:\Users\Administrator> 

Pros / contras subjetivos.

Pros:

• Un enfoque estándar para conectarse a los servidores.
  Cuando hay pocas máquinas con Windows, es muy inconveniente cuando:
  Entonces, aquí vamos por ssh, y aquí rdp,
  y, en general, las mejores prácticas con bastiones, primero un túnel ssh y, a través de él, RDP.
• Configuración fácil
  Creo que esto es obvio.
• Velocidad de conexión y trabajo con una máquina remota.
  No hay un shell gráfico; se guardan tanto los recursos del servidor como la cantidad de datos transmitidos.

Contras:

• No reemplaza RDP por completo.
  No todo se puede hacer desde la consola, por desgracia. Me refiero a situaciones en las que se requiere una GUI.

Materiales utilizados en el artículo:
Enlace al proyecto en sí
Opciones de instalación copiadas descaradamente de documentos de Ansible .