Conéctese a Windows a través de SSH como en Linux

Lo más deprimente para mí es conectarme a los hosts de Windows. No soy un oponente o un fanático de Microsoft y sus productos. Cada producto tiene su propio propósito. Pero es realmente doloroso para mí conectarme a los servidores de Windows, debido a 2 puntos: es difícil de configurar (Hola WinRM con HTTPS) y es realmente inestable (Hola RDP para máquinas virtuales a través del océano).

Afortunadamente, encontré el proyecto Win32-OpenSSH . Me di cuenta de que quiero compartir mi experiencia con él. Creo que ayudará a alguien y ahorrará muchos nervios.



Formas de instalación:

1. Manualmente
2. Vía paquete Chocolatey
3. Vía Ansible, digamos el papel jborean93.win_openssh

Explicaré la forma manual porque otras son obvias.

Debo señalar que este proyecto está en etapa beta y no se recomienda usarlo en producción.

Bueno, descarguemos la última versión. Actualmente es 7.9.0.0p1-beta . También tiene versiones de 32 y 64 bits.

Luego descomprímalo en C: \ Archivos de programa \ OpenSSH .

Importante: Es necesario otorgar acceso de escritura al SISTEMA y al grupo Administradores solamente.

Además, instale servicios a través de la secuencia de comandos de instalación install-sshd.ps1 que se encuentra en el directorio OpenSSH

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

Permitamos conexiones entrantes en el puerto 22:

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

Nota: el applet New-NetFirewallRule es solo para Windows Server 2012 y superior. Para sistemas operativos más antiguos o de escritorio, puede usar el siguiente comando:

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

Comience el servicio:

 net start sshd 

Esto generará automáticamente claves de host en % programdata% \ ssh si aún no existen.

Puede configurar el inicio automático del servicio mediante el comando:

 Set-Service sshd -StartupType Automatic 

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

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

Nota: debe definir la ruta absoluta.

Que sigue

Podemos configurar sshd_config , que se encuentra en C: \ ProgramData \ ssh .
Por ejemplo:

 PasswordAuthentication no PubkeyAuthentication yes 

Luego creamos el directorio .ssh dentro del directorio del usuario ( C: \ Users \ <user_directory> ) y el archivo autorizado_keys dentro de él. Podemos pegar claves públicas en este archivo.
Importante: el único usuario en qué directorio se encuentra debe tener permisos de escritura para este archivo.
Por cierto, si no puede solucionarlo, puede desactivar la verificación de permisos a través de config:

 StrictModes no 

Además, el directorio C: \ Archivos de programa \ OpenSSH contiene 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), que no deben obligar a corregir los permisos, incluidos los permisos de claves autorizadas , pero no lo hacen.

No olvide reiniciar el servicio sshd para 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 personales.

Pros:

• Manera estándar de conectarse a cualquier servidor (Windows / Linux)
  Cuando tiene algunos hosts de Windows, es inconveniente:
  Entonces, aquí vamos por ssh, pero aquí por RDP,
  y, en general, es la mejor práctica con bastiones, primero ssh-tunnel, luego RDP a través del túnel. Oh, mátame bebé una vez más.
• Fácil de configurar
  Creo que es obvio.
• Velocidad de conexión al host remoto
  Sin GUI, ahorramos recursos del host y el tamaño de los datos transmitidos

Contras:

• No puede reemplazar RDP en algunos casos.
  No todas las cosas que puedes hacer a través de PowerShell. Me refiero a los casos en que se requiere GUI.

Enlaces:

Proyecto en github
Documentos Ansible