Conexión a Windows por SSH como en Linux

Siempre me ha desalentado conectarme a máquinas con Windows. No soy un opositor ni un defensor de Microsoft y sus productos. Cada producto existe con un propósito, pero no es de eso de lo que se trata.
Siempre ha sido doloroso para mí conectarme a servidores con Windows, porque esas conexiones o se configuran de una manera compleja (hola WinRM con HTTPS) o no son muy estables (saludos RDP a las máquinas virtuales al otro lado del océano).

Por lo tanto, al encontrar accidentalmente el proyecto Win32-OpenSSH, decidí compartir mi experiencia de configuración. Tal vez esta herramienta le ahorre a alguien un montón de nervios.

Opciones de instalación:

1. De forma manual
2. A través de paquete Chocolatey
3. A través de Ansible, por ejemplo, el rol jborean93.win_openssh

A continuación, hablaré sobre el primer punto, ya que los otros son más o menos claros.

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

Así que descargamos la última versión, que en este momento es 7.9.0.0p1-beta. Hay versiones tanto para sistemas de 32 como de 64 bits.

Descomprimimos en C:Program FilesOpenSSH
Un punto obligatorio para el funcionamiento correcto: los permisos de escritura en este directorio deben ser solo para SYSTEM y para el grupo de administradores.

Instalamos los servicios con el script install-sshd.ps1 que se encuentra en este directorio

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

Permitimos conexiones entrantes en el 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 utiliza en Windows Server 2012 y versiones posteriores. En sistemas más antiguos (o de escritorio) se puede utilizar el comando:

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

Iniciamos el servicio:

net start sshd

Al iniciarse, se generarán automáticamente las claves host (si no existen) en %programdata%ssh

Podemos habilitar el inicio automático del servicio al iniciar el sistema con el comando:

Set-Service sshd -StartupType Automatic

También se puede cambiar la shell por defecto (después de la instalación, por defecto es cmd):

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

Aclaración: Es necesario especificar una ruta absoluta.

¿Qué sigue?

Y a continuación configuramos sshd_config, que se ubicará en C:ProgramDatasshPor ejemplo:

PasswordAuthentication no
PubkeyAuthentication yes

Y creamos en la carpeta del usuario el directorio .ssh, y dentro de él el archivo authorized_keys. Ahí escribimos las claves públicas.

Importante aclaración: solo el usuario en cuyo directorio se encuentra el archivo debe tener derechos de escritura en este archivo.

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

StrictModes no

Por cierto, en C:Program FilesOpenSSH hay 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), que deberían pero no necesariamente corrigen los permisos, incluso con authorized_keys, pero por alguna razón no lo hacen.

No olvide reiniciar el servicio sshd después 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. Todos los derechos reservados.

PS C:UsersAdministrator> Get-Host


Nombre             : ConsoleHost
Versión          : 5.1.14393.2791
InstanceId       : 653210bd-6f58-445e-80a0-66f66666f6f6
Interfaz de usuario               : System.Management.Automation.Internal.Host.InternalHostUserInterface
Cultura actual   : en-US
Cultura de la IU actual : en-US
Datos privados      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

PS C:UsersAdministrator>

Pros y contras subjetivos.

Pros:

• Enfoque estándar para conectarse a servidores.
  Cuando hay algunas máquinas Windows, es muy incómodo cuando:
  Así que aquí entramos por ssh, y aquí rdp,
  y en general las mejores prácticas con bastiones, primero ssh-túnel, y a través de él RDP.
• Facilidad de configuración
  Creo que es obvio.
• Velocidad de conexión y trabajo con la máquina remota
  No hay interfaz gráfica, se ahorran tanto los recursos del servidor como la cantidad de datos transmitidos.

Desventajas:

• No reemplaza completamente RDP.
  No se puede hacer todo desde la consola, lamentablemente. Me refiero a situaciones donde se requiere una GUI.

Materiales utilizados en el artículo:
Enlace al propio proyecto
Las opciones de instalación están vergonzosamente copiadas de Ansible docs.

Fuente: habr.com