Habilitar e usar o PowerShell remoting: WinRM, TrustedHosts e o limite do segundo salto

Objetivo

Ativar o PowerShell remoting em um host Windows Server 2019/2022/2025 e operá-lo a partir de uma sessão de agente, seja localmente via WinRM, seja via SSH quando apenas a porta 22 está aberta, sem deixar para trás uma configuração de confiança excessivamente ampla.

Pré-requisitos

Direitos de administrador local no destino; o serviço WinRM com permissão para iniciar; para um destino fora de domínio ou uma conexão por endereço IP, um listener HTTPS com certificado ou uma entrada explícita em TrustedHosts, definida na máquina que inicia a conexão.

Passos

1. Verifique o estado atual: Get-Service WinRM; Test-WSMan SRV1.
2. Habilite o remoting de forma não interativa: Enable-PSRemoting -Force -SkipNetworkProfileCheck. Isso inicia o serviço WinRM, configura-o para iniciar automaticamente e cria o listener padrão e a regra de firewall; o -Force suprime os pedidos de confirmação de cada etapa, para que a chamada não fique travada em uma execução sem supervisão.
3. Se o destino não estiver ingressado em um domínio, ou se você precisar se conectar por IP em vez de nome, a autenticação mútua Kerberos não está disponível. A própria orientação de solução de problemas da Microsoft afirma: "If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting." (Se o esquema de autenticação for diferente de Kerberos, ou se o computador cliente não estiver ingressado em um domínio, é preciso usar o transporte HTTPS ou adicionar a máquina de destino à configuração TrustedHosts.) Prefira um listener HTTPS com certificado; use Set-Item WSMan:\localhost\Client\TrustedHosts -Value '10.0.0.5' -Force apenas se aceitar que o TrustedHosts dispensa a verificação da identidade do servidor.
4. Execute tarefas não interativas com Invoke-Command -ComputerName SRV1 -Credential $cred -ScriptBlock { Get-Service }; use Enter-PSSession -ComputerName SRV1 somente para diagnóstico interativo, e não dentro de scripts sem supervisão, pois ele fica bloqueado aguardando uma entrada.
5. Onde apenas o SSH está aberto, ou em ambientes com plataformas mistas, o PowerShell 7 pode fazer remoting via SSH em vez de WinRM, desde que o OpenSSH Server tenha o subsistema do PowerShell configurado: Invoke-Command -HostName SRV1 -UserName admin -SSHTransport -ScriptBlock { hostname }.

Resultado esperado

Test-WSMan retorna um objeto de resposta, Invoke-Command devolve a saída sem solicitar nenhuma entrada e uma sessão baseada em SSH se autentica no subsistema configurado.

Limites e base de verificação

As credenciais usadas para abrir uma sessão remota não são repassadas a um segundo computador remoto acessado de dentro dessa sessão (a documentação da Microsoft chama isso de "the second hop", o segundo salto), porque o token não é delegado por padrão; CredSSP ou a delegação restrita baseada em recursos do Kerberos são as soluções alternativas documentadas, cada uma com suas próprias compensações. Para desfazer: Disable-PSRemoting -Force e Clear-Item WSMan:\localhost\Client\TrustedHosts removem o que os passos 2 e 3 adicionaram; faça antes um backup do valor atual de TrustedHosts com (Get-Item WSMan:\localhost\Client\TrustedHosts).Value, caso outra automação dependa dele. Nenhum desses passos exige reinicialização; é necessária uma nova sessão do PowerShell para que alterações em $PSSessionConfigurationName tenham efeito.