Conecte-se ao Windows via SSH como no Linux

A coisa mais deprimente para mim é conectar-me aos hosts do Windows. Eu não sou um oponente ou um fã dos produtos da Microsoft e deles. Todo produto tem seu próprio objetivo. Mas é realmente doloroso para mim me conectar aos servidores Windows, devido a dois pontos: é difícil de configurar (Hi WinRM com HTTPS) e é realmente instável (Olá RDP para VMs do outro lado do oceano).

Felizmente, encontrei o projeto Win32-OpenSSH . Percebi que quero compartilhar minha experiência com ele. Acredito que ajudará alguém e poupará muitos nervos.



Maneiras da instalação:

1. Manualmente
2. Via pacote Chocolatey
3. Via Ansible, digamos o papel jborean93.win_openssh

Vou explicar a maneira manual, porque outras são óbvias.

Devo observar que este projeto está no estágio beta e não é recomendável usá-lo na produção.

Bem, vamos baixar a versão mais recente. Atualmente, é 7.9.0.0p1-beta . Também possui versões de 32 e 64 bits.

Em seguida, descompacte-o em C: \ Arquivos de Programas \ OpenSSH .

Importante: É necessário conceder acesso de gravação apenas ao grupo SISTEMA e Administradores.

Além disso, instale serviços por meio do script shell install-sshd.ps1, localizado no diretório OpenSSH

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

Vamos permitir conexões de entrada na porta 22:

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

Nota: o applet New-NetFirewallRule é apenas para Windows Server 2012 e superior. Para sistemas operacionais mais antigos ou de desktop, você pode usar o seguinte comando:

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

Inicie o serviço:

 net start sshd 

Isso gerará automaticamente chaves de host em % programdata% \ ssh se elas ainda não existirem.

Você pode configurar o serviço de inicialização automática por comando:

 Set-Service sshd -StartupType Automatic 

Além disso, você pode alterar o shell padrão (é cmd por padrão após a instalação):

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

Nota: você deve definir o caminho absoluto.

O que vem a seguir?

Podemos configurar o sshd_config , localizado em C: \ ProgramData \ ssh .
Ex .:

 PasswordAuthentication no PubkeyAuthentication yes 

Em seguida, criamos o diretório .ssh dentro do diretório do usuário ( C: \ Users \ <diretório_do_usuário> ) e o arquivo allowed_keys dentro dele. Podemos colar chaves públicas nesse arquivo.
Importante: o único usuário em que diretório está, deve ter permissões de gravação para este arquivo.
A propósito, se você não pode corrigi-lo, pode desativar a verificação de permissões via config:

 StrictModes no 

Além disso, o diretório C: \ Arquivos de Programas \ OpenSSH contém 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), que devem, mas não devem, obrigar as permissões de correção, incluindo as permissões allowed_keys , mas não.

Não se esqueça de reiniciar o serviço sshd para aplicar as alterações.

 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> 

Prós / contras pessoais.

Prós:

• Maneira padrão de conectar-se a qualquer servidor (Windows / Linux)
  Quando você tem alguns hosts Windows, é inconveniente:
  Então, aqui vamos nós via ssh, mas aqui via RDP,
  e de um modo geral, é a melhor prática com bastiões, primeiro túnel ssh, depois RDP através do túnel. Oh me mate, querida, mais uma vez.
• Fácil de configurar
  Eu acho que é óbvio.
• Velocidade de conexão com o host remoto
  Sem GUI, economizamos recursos do host e tamanho dos dados transmitidos

Contras:

• Não pode substituir o RDP em alguns casos.
  Nem todas as coisas que você pode fazer via PowerShell. Quero dizer os casos em que a GUI é necessária.

Ligações:

Projeto no github
Documentos possíveis