ProHoster > Blog > administração > Conectando-se ao Windows via SSH como Linux

Conectando-se ao Windows via SSH como Linux

Sempre fiquei frustrado ao conectar-me a máquinas Windows. Não, não sou oponente nem apoiador da Microsoft e de seus produtos. Cada produto existe para seu próprio propósito, mas não é disso que se trata.
Sempre foi terrivelmente doloroso para mim conectar-me a 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, tendo acidentalmente encontrado o projeto Win32-OpenSSH, decidi compartilhar minha experiência de configuração. Talvez esta ferramenta poupe muitos nervos a alguém.

Conectando-se ao Windows via SSH como Linux

Opções de instalação:

  1. manualmente
  2. Através pacote Chocolatey
  3. Via Ansible, por exemplo, função jborean93.win_openssh

A seguir falarei do primeiro ponto, já que tudo fica mais ou menos claro com o resto.

Gostaria de ressaltar que este projeto ainda está em fase beta, portanto não é recomendado utilizá-lo em produção.

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

Desembale em C:Arquivos de ProgramasOpenSSH
Ponto obrigatório para o correto funcionamento: somente o SISTEMA e o grupo de administração.

Instalando serviços usando um script instalar-sshd.ps1 localizado neste diretório

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

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

Esclarecimento: miniaplicativo Nova regra NetFirewall usado no Windows Server 2012 e posterior. Nos sistemas mais antigos (ou desktop) 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 serão geradas automaticamente (se faltarem) em %dados do programa%ssh

Podemos habilitar a inicialização automática do serviço quando o sistema iniciar com o comando:

Set-Service sshd -StartupType Automatic

Você também pode alterar o shell de comando padrão (após a instalação, o padrão é cmd):

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

Esclarecimento: você deve especificar um caminho absoluto.

Qual é o próximo?

E então nós configuramos sshd_config, que colocaremos em C: Dados do Programa. Por exemplo:

PasswordAuthentication no
PubkeyAuthentication yes

E crie um diretório na pasta do usuário .ssh, e nele o arquivo autorizado_chaves. Anotamos as chaves públicas lá.

Esclarecimento importante: somente o usuário em cujo diretório o arquivo está localizado deve ter o direito de gravar neste arquivo.

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

StrictModes no

A propósito, em C:Arquivos de ProgramasOpenSSH existem 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), que deveriam, mas não são obrigados, a fixar direitos, inclusive com autorizado_chaves, mas por algum motivo eles não se registram.

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

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>

Prós/contras subjetivos.

Prós:

  • Abordagem padrão para conexão com servidores.
    Quando há poucas máquinas Windows, é muito inconveniente quando:
    Então, aqui vamos via ssh, e aqui usamos rdp,
    e, em geral, a prática recomendada com bastiões é primeiro um túnel ssh e o RDP através dele.
  • Fácil de configurar
    Eu acho que isso é óbvio.
  • Velocidade de conexão e trabalho com máquina remota
    Não há shell gráfico, economizando recursos do servidor e a quantidade de dados transmitidos.

Contras:

  • Não substitui completamente o RDP.
    Infelizmente, nem tudo pode ser feito no console. Quero dizer situações em que uma GUI é necessária.

Materiais utilizados no artigo:
Link para o próprio projeto
As opções de instalação são copiadas descaradamente de Documentos Ansible.

Fonte: habr.com

Adicionar um comentário