ProHoster > Blog > Administración > Conexión a Windows mediante SSH como Linux

Conexión a Windows mediante SSH como Linux

Sempre me frustrou conectarme a máquinas Windows. Non, non son nin un opoñente nin un partidario de Microsoft e os seus produtos. Cada produto existe para o seu propio propósito, pero non se trata diso.
Sempre foi tremendamente doloroso para min conectarme a servidores Windows, porque estas conexións están configuradas a través dun só lugar (ola WinRM con HTTPS) ou non funcionan de forma moi estable (ola RDP para máquinas virtuais no exterior).

Polo tanto, ao atoparse accidentalmente co proxecto Win32-OpenSSH, decidín compartir a miña experiencia de configuración. Quizais esta ferramenta aforrará a alguén moitos nervios.

Conexión a Windows mediante SSH como Linux

Opcións de instalación:

  1. A man
  2. A través paquete Chocolatey
  3. Vía Ansible, por exemplo rol jborean93.win_openssh

A continuación, falarei do primeiro punto, xa que todo está máis ou menos claro co resto.

Gustaríame sinalar que este proxecto aínda está en fase beta, polo que non se recomenda usalo na produción.

Entón, descarga a última versión, neste momento 7.9.0.0p1-beta. Hai versións para sistemas de 32 e 64 bits.

Desembalar C:Arquivos de programasOpenSSH
Un punto obrigatorio para un correcto funcionamento: só o SISTEMA e o grupo de administradores.

Instalación de servizos mediante un script install-sshd.ps1 situado neste directorio

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

Permitir conexións entrantes no porto 22:

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

Aclaración: applet Nova regra NetFirewall usado en Windows Server 2012 e posteriores. Nos sistemas (ou escritorio) máis antigos pode usar o comando:

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

Comezamos o servizo:

net start sshd

No inicio, xeraranse automaticamente as claves de host (se faltan). %programdata%ssh

Podemos activar o inicio automático do servizo cando o sistema se inicia co comando:

Set-Service sshd -StartupType Automatic

Tamén pode cambiar o shell de comandos predeterminado (despois da instalación, o predeterminado é cmd):

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

Aclaración: debes especificar un camiño absoluto.

Cal é o próximo?

E despois configuramos sshd_config, que situaremos C: Datos do programa. Por exemplo:

PasswordAuthentication no
PubkeyAuthentication yes

E crea un directorio no cartafol do usuario .ssh, e nel o ficheiro chaves_autorizadas. Anotamos alí as chaves públicas.

Aclaración importante: só o usuario en cuxo directorio se atopa o ficheiro debería ter dereito a escribir neste ficheiro.

Pero se tes problemas con isto, sempre podes desactivar a comprobación de dereitos na configuración:

StrictModes no

Por certo, en C:Arquivos de programasOpenSSH hai 2 guións (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), que deberían, pero non están obrigados a fixar dereitos, incluso con chaves_autorizadas, pero por algún motivo non se rexistran.

Non esquezas reiniciar o servizo ssh despois de aplicar os 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/contras subxectivos.

Pros:

  • Enfoque estándar para conectarse a servidores.
    Cando hai poucas máquinas Windows, é moi inconveniente cando:
    Entón, aquí imos a través de ssh, e aquí usamos rdp,
    e, en xeral, a mellor práctica con bastións é primeiro un túnel ssh e RDP a través del.
  • Facilidade de configuración
    Creo que isto é obvio.
  • Velocidade de conexión e traballo cunha máquina remota
    Non hai shell gráfico, aforrando tanto os recursos do servidor como a cantidade de datos transmitidos.

Contras:

  • Non substitúe completamente RDP.
    Non todo se pode facer dende a consola, por desgraza. Refírome a situacións nas que se require unha GUI.

Materiais utilizados no artigo:
Ligazón ao propio proxecto
As opcións de instalación son copiadas sen vergoña Ansible docs.

Fonte: www.habr.com

Engadir un comentario