WinRM e evil-winrm-py: administrando Windows Server a partir do Linux

Sempre gostei de utilizar Linux. No meu dia a dia, abrir um terminal e administrar servidores por SSH é algo natural. Conheço o fluxo, sei como investigar processos, consultar logs, acompanhar serviços e executar uma correção sem precisar abrir uma interface gráfica.

Com Windows Server, a experiência era diferente. Quando precisava administrar um servidor Windows, eu quase sempre sentia que estava começando de trás. O PowerShell nunca foi a minha ferramenta preferida e, principalmente, eu não tinha um caminho tão direto para acessar o servidor a partir do meu terminal Linux.

Esse problema ficou mais evidente quando comecei a utilizar agentes de IA. Eles ajudam muito a diagnosticar problemas, interpretar mensagens de erro e sugerir soluções. Posso pedir que um agente investigue um serviço, compare configurações ou monte um roteiro de diagnóstico. Mas ainda existia uma pergunta básica: como o agente, executando no meu Linux, acessaria o terminal do Windows Server?

Foi quando a própria IA me falou do WinRM.

O que é o WinRM

O Windows Remote Management, ou WinRM, é o mecanismo de gerenciamento remoto baseado em WS-Management presente no Windows. Ele permite abrir uma sessão remota e executar comandos no servidor, inclusive comandos do PowerShell.

Eu já tinha o SSH como referência. O WinRM não é SSH e não funciona da mesma maneira, mas resolve uma necessidade parecida no universo Windows: em vez de depender de uma área de trabalho remota, posso administrar o servidor por uma sessão de terminal.

Por padrão, o WinRM costuma utilizar a porta 5985 com HTTP. Também é possível configurar HTTPS, normalmente na porta 5986. Em um ambiente de produção, especialmente quando o tráfego atravessa redes que não são totalmente confiáveis, é importante planejar o uso de HTTPS, certificado, autenticação e regras de firewall. Não basta abrir uma porta e considerar o problema resolvido.

Preparando o Windows Server

A configuração inicial é relativamente simples e rápida. No Windows Server, abro o PowerShell ou o Prompt de Comando como administrador e executo:

winrm quickconfig

O comando pode solicitar confirmação. Depois de confirmar, o Windows configura o serviço WinRM, cria um listener padrão e ajusta a exceção correspondente no firewall. Em um servidor compatível, essa é a parte que faltava para ele começar a aceitar solicitações de gerenciamento remoto.

Ainda assim, o resultado depende do ambiente. Depois do quickconfig, verifico se existe um listener:

winrm enumerate winrm/config/listener

Também posso consultar a configuração geral:

winrm get winrm/config

Em um domínio, a autenticação e a resolução de nomes normalmente se integram melhor ao Kerberos ou ao Negotiate. Em um workgroup ou em uma conexão feita por endereço IP, pode ser necessário revisar o usuário, o método de autenticação e a configuração de TrustedHosts. Essa lista deve ser restrita aos hosts realmente necessários, porque confiar em qualquer computador diminui a segurança da conexão.

O winrm quickconfig é um ponto de partida, não uma autorização ampla para qualquer máquina da rede. O servidor precisa estar protegido por firewall, o usuário remoto precisa ter permissão e a conexão deve ser feita somente em máquinas próprias ou explicitamente autorizadas.

Do Linux para o PowerShell

Depois de entender o WinRM, encontrei o evil-winrm-py. Apesar do nome lembrar uma ferramenta de segurança, o que me interessou foi o uso como cliente Python para administração remota autorizada.

A instalação no Linux é simples. Posso usar pipx, uv ou um ambiente virtual Python para não misturar as dependências com o restante do sistema. Com pipx, por exemplo:

pipx install evil-winrm-py

Ou, dentro de um ambiente virtual:

python3 -m venv ~/.venvs/evil-winrm-py
source ~/.venvs/evil-winrm-py/bin/activate
python -m pip install evil-winrm-py

Para abrir uma sessão em um servidor autorizado, informo o endereço e o usuário. Se eu não passar a senha na linha de comando, o programa pode solicitá-la de forma interativa:

evil-winrm-py -i <servidor-windows> -u '<dominio\\usuario>'

Para uma conta local, o formato do usuário depende da configuração do servidor. Em alguns ambientes, uso o nome do servidor como domínio ou o formato aceito pela política local. O importante é não colocar uma senha real no histórico do shell, em um script público ou no texto de uma solicitação para um agente.

Quando o servidor tem um listener HTTPS configurado, a conexão pode ser feita com --ssl:

evil-winrm-py -i <servidor-windows> -u '<dominio\\usuario>' --ssl

Depois da autenticação, recebo um shell interativo do PowerShell no terminal Linux. A sensação é diferente de utilizar SSH, mas a ideia de trabalho volta a ser familiar: conecto, verifico o estado do servidor e executo apenas os comandos necessários.

Diagnóstico pelo terminal

O acesso remoto só faz sentido para mim porque posso usar o terminal para investigar problemas. Alguns comandos de leitura que ajudam no primeiro diagnóstico são:

$env:COMPUTERNAME
Get-Service
Get-Process
Get-WinEvent -LogName System -MaxEvents 20

Com eles, consigo confirmar em qual servidor estou, consultar os serviços, observar processos e buscar eventos recentes do sistema. Dependendo do problema, também posso verificar espaço em disco, conectividade, tarefas agendadas, atualizações e o estado de um serviço específico.

Eu costumo começar por ações de leitura. Primeiro entendo o que está acontecendo, depois avalio a mudança. Isso é ainda mais importante quando o diagnóstico é feito por um agente: um comando que parece simples pode alterar o estado de um servidor se não for revisado antes.

Onde os agentes de IA entram

O WinRM resolveu a parte que estava faltando no meu fluxo. O agente já era bom para analisar sintomas e sugerir caminhos, mas agora também existe um meio de chegar ao ambiente Windows pelo terminal.

Posso pedir a um agente para conectar a um servidor autorizado, consultar o nome da máquina, verificar um serviço e analisar os eventos recentes. A sequência que imagino é simples:

1. Informo ao agente qual servidor deve ser analisado e qual é o objetivo do diagnóstico.
2. Acesso o servidor com uma credencial fornecida de forma segura, sem colocá-la no prompt ou no repositório.
3. Executo primeiro comandos de leitura e coleto as saídas relevantes.
4. Peço ao agente que organize os sintomas, relacione os eventos e proponha os próximos passos.
5. Reviso qualquer alteração antes de permitir que ela seja executada.

O agente não substitui a autorização nem a revisão humana. Ele pode ajudar a interpretar um evento, lembrar um comando do PowerShell e reduzir o tempo de investigação, mas a responsabilidade pela mudança continua sendo de quem administra o servidor.

Também é possível automatizar esse fluxo com scripts e integrações, mas prefiro começar com uma sessão controlada. Credenciais devem ficar em um gerenciador de segredos ou em um mecanismo seguro de execução, e as sessões precisam ser registradas de acordo com a política do ambiente.

Minha relação com o Windows mudou

Eu nunca gostei muito do Windows e muito menos do PowerShell. Ainda prefiro Linux, seus utilitários e a simplicidade do SSH. Mas o acesso remoto deixou de ser uma barreira tão grande.

O WinRM me deu um caminho de terminal para chegar ao Windows Server. O winrm quickconfig torna a preparação inicial objetiva, e o evil-winrm-py oferece uma forma prática de abrir a sessão a partir do Linux. A partir daí, os agentes de IA conseguem participar do diagnóstico de uma maneira muito mais natural para mim.

Isso não transforma o Windows em Linux e não faz o PowerShell se comportar como Bash. A diferença é que agora não preciso abandonar o meu fluxo de trabalho para administrar um servidor Windows. Posso permanecer no Linux, acessar o PowerShell quando necessário e usar a IA para me ajudar a entender o que está acontecendo.

Para quem também administra ambientes mistos, essa combinação é útil: Linux como estação de trabalho, WinRM como transporte de gerenciamento, PowerShell como interface do Windows e um agente de IA como apoio para investigação. O resultado não elimina a complexidade do Windows Server, mas torna as tarefas e os diagnósticos bem mais acessíveis.

O projeto evil-winrm-py e a documentação do WinRM da Microsoft explicam os detalhes para quem quiser experimentar. Use sempre essas ferramentas somente em servidores que você administra ou para os quais recebeu autorização explícita.