Conectando-se ao Windows via SSH como no Linux

Eu sempre estava deprimido pela conexão com as máquinas Windows. Não, eu não sou um oponente ou apoiador da Microsoft e de seus produtos. Cada produto existe para o seu propósito, mas não se trata disso.
Sempre foi doloroso para mim me conectar aos servidores Windows, porque essas conexões são configuradas em um único local (olá, WinRM com HTTPS) ou não funcionam de maneira muito estável (olá, RDP para máquinas virtuais no exterior).

Portanto, acidentalmente deparei com um projeto Win32-OpenSSH , decidi compartilhar a experiência de configuração. Talvez alguém dessa ferramenta economize um monte de nervos.



Opções de instalação:

1. Manualmente
2. Via Pacote Chocolatey
3. Via Ansible, por exemplo, função jborean93.win_openssh

A seguir, falarei sobre o primeiro ponto, como no resto, e tudo fica mais ou menos claro.

Observo que este projeto ainda está na versão beta, portanto não é recomendado para uso na produção.

Portanto, baixe a versão mais recente, atualmente é 7.9.0.0p1-beta . Existem versões para sistemas de 32 e 64 bits.

Descompacte em C: \ Arquivos de Programas \ OpenSSH
Momento obrigatório para o trabalho correto: somente SYSTEM e o grupo de administradores devem ter permissões de gravação neste diretório.

Instale serviços com o script install-sshd.ps1 localizado neste diretório

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

Permitir conexões de entrada para a porta 22:

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

Esclarecimento: o applet New-NetFirewallRule é usado no Windows Server 2012 e posterior. Nos sistemas mais antigos (ou na área de trabalho), você pode usar o comando:

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

Iniciamos o serviço:

 net start sshd 

Na inicialização, as chaves do host (se ausentes) serão geradas automaticamente em % programdata% \ ssh

Inicialização automática do serviço na inicialização do sistema, podemos ativar com o comando:

 Set-Service sshd -StartupType Automatic 

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

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

Especificação: Um caminho absoluto deve ser especificado.

O que vem a seguir?

E então configure sshd_config , que colocaremos em C: \ ProgramData \ ssh . Por exemplo:

 PasswordAuthentication no PubkeyAuthentication yes 

E crie o diretório .ssh na pasta do usuário e nele o arquivo allowed_keys . Escrevemos chaves públicas lá.

Um esclarecimento importante: somente o usuário em cujo diretório o arquivo está localizado deve ter permissões de gravação para esse arquivo.

Mas se você tiver problemas com isso, sempre poderá desativar a verificação de direitos na configuração:

 StrictModes no 

A propósito, em C: \ Arquivos de Programas \ OpenSSH, existem 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), que devem, mas não são necessários, para corrigir os direitos, inclusive com as teclas_autorizadas , mas por algum motivo eles não serão corrigidos.

Lembre-se de reiniciar o serviço sshd depois de 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 subjetivos.

Prós:

• Uma abordagem padrão para conectar-se a servidores.
  Quando existem poucas máquinas Windows, é muito inconveniente quando:
  Então, aqui vamos nós por ssh, e aqui rdp,
  e geralmente as melhores práticas com bastiões, primeiro um túnel ssh e, por meio dele, RDP.
• Configuração fácil
  Eu acho que isso é óbvio.
• Velocidade de conexão e trabalho com uma máquina remota
  Não há shell gráfico; os recursos do servidor e a quantidade de dados transmitidos são salvos.

Contras:

• Não substitui o RDP completamente.
  Nem tudo pode ser feito a partir do console, infelizmente. Quero dizer situações em que uma GUI é necessária.

Materiais utilizados no artigo:
Link para o próprio projeto
Opções de instalação copiadas descaradamente dos documentos Ansible .