Sempre me incomodou a conexão com máquinas Windows. Não sou um oponente nem um defensor da Microsoft e seus produtos. Cada produto existe para um propósito, mas não é sobre isso que estamos falando.
Sempre foi torturante para mim conectar a servidores Windows, porque essas conexões ou são configuradas de maneira complicada (olá WinRM com HTTPS) ou funcionam de forma instável (saudações RDP para VMs do outro lado do oceano).
Portanto, ao me deparar por acaso com o projeto , decidi compartilhar a experiência de configuração. Talvez essa ferramenta economize muitos nervos para alguém.
Opções de instalação:
- Através de Chocolatey
- Através do Ansible, por exemplo, o papel
A seguir, falarei sobre o primeiro item, pois os outros estão mais ou menos claros.
Vale destacar que este projeto ainda está em fase beta, portanto não é recomendado para uso em produção.
Então, fazemos o download da última versão, que no momento é . Existem versões tanto para sistemas de 32 quanto de 64 bits.
Descompactamos em C:\Program Files\OpenSSH
Um ponto obrigatório para o funcionamento correto: as permissões de gravação nesta diretório devem ser apenas para SYSTEM e para o grupo de administradores.
Instalamos os serviços com o script install-sshd.ps1 que está neste diretório
powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1Permitimos conexões de entrada na porta 22:
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22Observação: o applet New-NetFirewallRule é utilizado no Windows Server 2012 e versões mais recentes. Em sistemas mais antigos (ou de desktop) pode-se usar o comando:
netsh advfirewall firewall add rule name=sshd dir=in action=allow protocol=TCP localport=22
Iniciamos o serviço:
net start sshdAo iniciar, as chaves de host serão geradas automaticamente (se estiverem ausentes) em %programdata%\ssh
Podemos habilitar a inicialização automática do serviço no início do sistema com o comando:
Set-Service sshd -StartupType AutomaticAlém disso, é possível alterar o shell padrão (após a instalação, por padrão — cmd):
New-ItemProperty -Path "HKLM:SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -ForceObservação: é necessário especificar o caminho absoluto.
E agora?
E a seguir, configuramos sshd_config, que se encontra em C:\ProgramData\ssh. Por exemplo:
PasswordAuthentication no
PubkeyAuthentication yesE criamos no diretório do usuário a pasta .ssh, e dentro dela o arquivo authorized_keys. Ali, registramos as chaves públicas.
Uma observação importante: o arquivo deve ter permissões de gravação apenas para o usuário cuja diretório contém o arquivo.
Mas se você tiver problemas com isso, sempre pode desligar a verificação de permissões no arquivo de configuração:
StrictModes noA propósito, C:\Program Files\OpenSSH existem 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), que devem, mas não são obrigados a corrigir as permissões, incluindo authorized_keys, mas por alguma razão não corrigem.
Não se esqueça de reiniciar o serviço sshd. após 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. Todos os direitos reservados.
PS C:UsersAdministrator> Get-Host
Nome : ConsoleHost
Versão : 5.1.14393.2791
InstanceId : 653210bd-6f58-445e-80a0-66f66666f6f6
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : pt-BR
CurrentUICulture : pt-BR
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace
PS C:UsersAdministrator>Prós e contras subjetivos.
Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.
- Abordagem padrão para conexão com servidores.
Quando há algumas máquinas Windows, é muito inconveniente quando:
Aqui usamos ssh, e ali RDP,
e, na verdade, a melhor prática com bastion hosts é, primeiro, um túnel ssh, e, através dele, RDP. - Facilidade de configuração
Acredito que isso é óbvio. - Velocidade de conexão e trabalho com a máquina remota
Não há interface gráfica, economizando tanto os recursos do servidor quanto a quantidade de dados transmitidos.
Pontos negativos:
- Não substitui completamente o RDP.
Nem tudo pode ser feito a partir do console, infelizmente. Refiro-me a situações que exigem GUI.
Materiais utilizados no artigo:
As opções de instalação foram copiados escandalosamente de .
Fonte: habr.com
