ProHoster > Blog > administración > Conexión a Windows a través de SSH como Linux

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

Siempre me ha frustrado conectarme a máquinas con Windows. No, no soy ni oponente ni partidario de Microsoft y sus productos. Cada producto existe para su propio propósito, pero no se trata de eso.
Siempre ha sido extremadamente doloroso para mí conectarme a servidores de Windows, porque estas conexiones se configuran a través de un solo lugar (hola WinRM con HTTPS) o no funcionan de manera muy estable (hola RDP a máquinas virtuales en el extranjero).

Por lo tanto, al encontrarse accidentalmente con el proyecto. Win32-OpenSSH, Decidí compartir mi experiencia de configuración. Quizás esta herramienta le ahorre muchos nervios a alguien.

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

Opciones de instalación:

  1. a mano
  2. A través de пакет Chocolatey
  3. A través de Ansible, por ejemplo rol jborean93.win_openssh

A continuación hablaré del primer punto, ya que con el resto está todo más o menos claro.

Me gustaría señalar que este proyecto aún se encuentra en la etapa beta, por lo que no se recomienda utilizarlo en producción.

Entonces, descargue la última versión, en este momento es 7.9.0.0p1-beta. Existen versiones para sistemas tanto de 32 como de 64 bits.

Desempacar en C: Archivos de programa OpenSSH
Un punto obligatorio para el correcto funcionamiento: sólo el SISTEMA y el grupo de administración.

Instalación de servicios usando un script instalar-sshd.ps1 ubicado en este directorio

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

Permitir 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: subprograma Nueva regla NetFirewall utilizado en Windows Server 2012 y posteriores. En los sistemas (o de escritorio) más antiguos puedes usar el comando:

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

Comencemos el servicio:

net start sshd

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

Podemos habilitar el inicio automático del servicio cuando el sistema inicia con el comando:

Set-Service sshd -StartupType Automatic

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

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

Aclaración: Debe especificar una ruta absoluta.

¿Qué será lo próximo?

Y luego lo configuramos sshd_config, que colocaremos en C:Datos del programa. Por ejemplo:

PasswordAuthentication no
PubkeyAuthentication yes

Y cree un directorio en la carpeta del usuario. .ssh, y en él el archivo claves_autorizadas. Allí anotamos las claves públicas.

Aclaración importante: solo el usuario en cuyo directorio se encuentra el archivo debe tener derecho a escribir en este archivo.

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

StrictModes no

Por cierto, en C: Archivos de programa OpenSSH hay 2 guiones (RepararHostFilePermissions.ps1, RepararUserFilePermissions.ps1), que deberían, pero no están obligados, a fijar derechos, incluso con claves_autorizadas, pero por alguna razón no se registran.

No olvides reiniciar el servicio. sshd después de aplicar los cambios.

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>

Pros y contras subjetivos.

Pros:

  • Enfoque estándar para conectarse a servidores.
    Cuando hay pocas máquinas con Windows, resulta muy inconveniente cuando:
    Entonces, aquí vamos vía ssh, y aquí usamos rdp,
    y, en general, la mejor práctica con bastiones es primero un túnel ssh y RDP a través de él.
  • Fácil de configurar
    Creo que esto es obvio.
  • Velocidad de conexión y trabajo con una máquina remota
    No hay un shell gráfico, lo que ahorra recursos del servidor y la cantidad de datos transmitidos.

Contras:

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

Materiales utilizados en el artículo:
Enlace al proyecto en sí.
Las opciones de instalación se copian descaradamente de Documentos ansibles.

Fuente: habr.com

Añadir un comentario