O PowerShell Remoting (PSRemoting) é um dos recursos mais utilizados em todo o PowerShell. Por quê? Porque é muito útil mesmo! Usando um único comando, você pode conectar-se perfeitamente a um ou milhares de computadores remotos e executar comandos.
Neste Guia Definitivo, você mergulhará fundo no PSRemoting. Você aprenderá o que é, como funciona e todas as várias tecnologias que fazem o PSRemoting funcionar. Este guia não abordará como usar o PSRemoting. Você verá muitas referências a muitos de nossos guias de instruções ao longo do caminho.
Como o PSRemoting Funciona
Em poucas palavras, o PSRemoting permite que você execute comandos em computadores remotos como se estivesse na frente deles. O PSRemoting fornece um conjunto de recursos que conecta e autentica um usuário, executa comandos remotos e retorna qualquer saída desse comando para o computador local.
Pense no PSRemoting como telnet ou SSH ou até mesmo psexec. É apenas uma maneira de executar comandos em computadores dentro do PowerShell.
O PSRemoting depende muito de um conceito chamado sessão. Uma sessão é um termo usado para descrever um shell remoto que executa comandos dentro dele. O processo para criar uma dessas sessões passa por muitas etapas nos bastidores.
Ao iniciar uma sessão de PSRemoting, os seguintes passos aproximados são executados:
- O cliente tenta se conectar ao servidor de destino em um ouvinte WinRM (mais sobre ouvintes WinRM abaixo). Um ouvinte WinRM é um pequeno serviço web que executa no servidor de destino. WinRM é a implementação da Microsoft de um padrão chamado WSMan. WSMan é um padrão aberto criado com muitas outras grandes empresas de tecnologia na época como Dell, Intel e Sun Microsystems.
- Quando o cliente se conecta ao ouvinte através do protocolo HTTP ou HTTPS, o processo de autenticação começa. Todos os detalhes de cada método de autenticação serão cobertos mais tarde, mas por agora, apenas saiba que o cliente precisa passar credenciais para o servidor de alguma maneira.
- Após o cliente se conectar e autenticar no servidor, o PSRemoting cria uma sessão.
- Uma vez que o PSRemoting cria a sessão, então está aberto para negócios. Neste ponto, o cliente pode começar a enviar informações para o servidor com o servidor retornando qualquer saída necessária conhecida como serialização. Esta comunicação é tipicamente criptografada.
Ouvintes WinRM: Disponíveis para Conexão
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
Você pode descobrir todos os ouvintes WinRM executando em qualquer computador Windows usando o comando winrm abaixo.
Os ouvintes WinRM têm alguns componentes importantes. Eles têm:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- O tipo de transporte – Cada ouvinte WinRM precisa de uma maneira de se comunicar com o cliente; eles fazem isso por meio de um transporte usando HTTP ou HTTPS.
- Um thumbprint de certificado opcional – Quando um ouvinte WinRM usa HTTPS para o transporte, ele precisa saber qual chave privada usar para autenticar o cliente; essa chave é encontrada usando um thumbprint de certificado.
Use um ouvinte HTTPS sempre que possível. Configurar o transporte HTTPS aumenta a segurança, garantindo a validade do servidor e criptografando tanto a autenticação quanto o tráfego de transporte. Ao emitir um certificado, use um certificado confiável de uma autoridade de certificação, sempre que possível, em vez de um certificado autoassinado.
Hosts confiáveis: Validando um servidor
Como a Autenticação PSRemoting sobre WinRM Funciona
Como mencionado anteriormente, um dos primeiros passos que o PSRemoting passa é pela autenticação. A autenticação é uma das partes mais complicadas, mas essenciais, do PSRemoting.
Quando o PSRemoting foi introduzido pela primeira vez, ele tinha apenas um mecanismo de autenticação, o Windows Remote Management (WinRM), mas hoje em dia, você também pode autenticar usando SSH, como verá mais tarde.
O WinRM suporta dois tipos distintos de autenticação: nome de usuário e senha ou um certificado com vários tipos de autenticação para uma combinação de nome de usuário/senha.
Autenticação Básica
Começando pelo tipo mais fácil, porém menos seguro de autenticação é a autenticação básica. Este tipo de autenticação é um padrão incorporado no protocolo HTTP. A autenticação básica envia uma cópia codificada em base64 do nome de usuário e senha no cabeçalho HTTP do cliente para o ouvinte.
Porque a autenticação básica apenas codifica o nome de usuário e senha e não os criptografa, é trivial interceptar as credenciais pela rede.
Não use autenticação básica a menos que você absolutamente precise. Existem muitos outros métodos mais seguros que o WinRM pode autenticar!
Autenticação Kerberos
Se tanto o seu cliente quanto o servidor estiverem em um ambiente de Active Directory, você já está usando autenticação Kerberos em muitos dos seus serviços de rede.
Quando o cliente WinRM tenta se conectar a um ouvinte WinRM via Kerberos:
- O servidor primeiro tenta recuperar uma chave de sessão ou ticket-granting-ticket para o cliente de um controlador de domínio.
- O controlador de domínio verifica o cliente e o servidor e se ambos forem válidos e confiáveis, emite o token.
- O servidor então valida a conexão do cliente usando o token confiável em vez do nome de usuário e senha.
Durante a autenticação do Kerberos, o controlador de domínio valida tanto o cliente quanto o servidor durante as etapas de recuperação do ticket, impedindo que alguém mal-intencionado se faça passar pelo servidor.
O Kerberos é um método de autenticação maduro e seguro, sendo o tipo de autenticação padrão quando um cliente e um servidor são membros de um domínio Active Directory. No entanto, é necessário ambos o cliente e o servidor estarem associados ao mesmo domínio Active Directory ou com uma relação de confiança configurada entre domínios.
Autenticação Negociada
O WinRm também pode tentar usar o Kerberos e, se não estiver disponível, tentar usar um protocolo de autenticação chamado NT Lan Manager (NTLM).
Ao usar o NTLM:
- O servidor envia ao cliente uma string.
- O cliente, então, criptografa a string com um hash da senha do usuário.
- A string criptografada é então enviada de volta ao servidor, que envia o nome de usuário, a string original e a string criptografada para um controlador de domínio.
- O controlador de domínio, então, procura o hash da senha para esse usuário e repete o mesmo processo de criptografia na string para garantir que corresponda.
NTLM é bom para validar o cliente, mas, ao contrário do Kerberos, não valida o servidor. Isso abre espaço para vários ataques nos quais o servidor pode ser impostor por um atacante.
Você pode melhorar a segurança do NTLM ao também validar o servidor com um certificado de autenticação do servidor e atribuí-lo a um ouvinte WinRM HTTPS. Nessa configuração, o cliente é autenticado com NTLM contra o controlador de domínio, e o servidor é autenticado com um certificado confiável. Embora essa configuração forneça autenticação tanto para o cliente quanto para o servidor, o protocolo NLTM usa um cifrador de criptografia mais antigo com um tamanho de chave desatualizado.
Por essas razões, o NLTM só é utilizável se você adicionar o servidor à lista de hosts confiáveis ou usar um ouvinte HTTPS.
Autenticação Digest
Um dos métodos de autenticação menos comuns no WinRM é a autenticação Digest. NTLM e Digest são métodos de autenticação semelhantes. Assim como o NTLM, o Digest gera uma string única que é criptografada com o hash da senha do usuário. A senha não precisa ser enviada para o servidor.
O Digest usa o algoritmo de hash MD5 para criptografar a senha. Devido a essa escolha de algoritmo, o Digest geralmente é considerado obsoleto e não deve ser utilizado. O MD5 possui diversas vulnerabilidades conhecidas que o tornam inadequado para uso criptográfico.
Provedor de Suporte de Segurança de Credenciais (CredSSP)
Embora possamos entrar nos detalhes de CredSSP, não é necessário. Por quê? Porque quando se trata de PSRemoting e WinRM, o CredSSP é implementado geralmente por uma razão, o “problema do segundo salto”, que você aprenderá abaixo.
Quando configurado para autenticação CredSSP, tanto o cliente quanto o servidor WinRM usam a autenticação Negociar para autenticar tanto o usuário quanto o cliente. Mas uma vez concluído, a senha do usuário é enviada ao servidor.
Como a senha é enviada após o processo de autenticação ter sido concluído, ela é agora criptografada. O CredSSP também criptografa a senha com as chaves de sessão TLS para que a string criptografada seja única entre as sessões.
O CredSSP é útil porque, após a autenticação, o servidor pode se conectar a qualquer outra coisa em seu nome. No entanto, quando isso acontece, você está confiando totalmente no servidor ao qual se conectou com a senha do usuário.
Autenticação Baseada em Certificado
Indiscutivelmente, o método mais seguro de autenticação a ser usado com o PSRemoting é a autenticação baseada em certificado. Neste método de autenticação, ocorre uma troca de chaves típica com uma chave privada e pública no cliente e um servidor validando o certificado.
WinRM autentica o usuário mapeando um usuário no servidor dentro do WinRm. A única coisa que é passada durante o processo de autenticação é a chave pública, tornando-o um método muito seguro para autenticação
. Embora seja o mais seguro, a autenticação baseada em certificados não é muito comum. Por quê? Simplesmente devido ao trabalho necessário para configurá-la. Você deve:
- Construir uma autoridade de certificação
- Criar um certificado de autenticação do usuário
- Compartilhar a chave pública
- Usar uma conta de usuário local com permissões adequadas (provavelmente no grupo Administradores)
- Configurar um ouvinte HTTPS
- … e outros passos
Não é possível usar um usuário de domínio para autenticação com certificados, mesmo que o cliente e o servidor façam parte do Active Directory.
Configurações Padrão de Autenticação no Windows OS
Agora que você viu que existem muitas opções de autenticação disponíveis, como saber quais estão habilitadas por padrão? Abaixo, você verá uma tabela com duas colunas indicando se o cliente WinRM, por padrão, está habilitado e se aquele tipo específico de autenticação está habilitado por padrão.
Todos os tipos de autenticação mencionados podem ser configurados, mas usar a tabela abaixo lhe dará uma boa ideia do que precisará configurar por conta própria.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
O Problema do Segundo Salto ou Problema do Duplo Salto
Um dos maiores problemas com o PSRemoting é conhecido como o “problema do segundo salto” ou “duplo salto”. Essa situação ocorre quando você se conecta a um sistema remoto via PSRemoting e depois precisa se conectar a outro computador remoto.
Essa situação é problemática porque, quando o cliente WinRm se autentica no primeiro computador remoto, o servidor valida apenas a identidade do cliente de origem sem enviar a senha para o servidor. Ao tentar se conectar ao segundo computador a partir do servidor da primeira conexão, o servidor final não tem maneira de validar a identidade do usuário.
Você pode resolver o problema do duplo salto de algumas maneiras diferentes, seja usando CredSSP ou Delegação Kerberos.
Usando CredSSP
A maneira mais comum de contornar o problema do duplo salto é usando o CredSSP. A autenticação CredSSP contorna essa situação armazenando as credenciais do usuário no primeiro servidor remoto, as quais o servidor transformado em cliente pode então passar para o segundo servidor remoto.
Há um detalhe ao usar o CredSSP, no entanto. As credenciais do usuário armazenadas no primeiro servidor remoto podem ser salvas em texto simples, introduzindo assim uma preocupação óbvia com a segurança. Em sistemas operacionais mais recentes, é usado um hash da senha e do Ticket de Concessão de Ticket Kerberos (TGT). Esses podem ser usados juntos para autenticar como o usuário em qualquer lugar da rede, assim como uma senha em texto simples, mas isso reduz um pouco o risco.
Com o Negociar, o cliente e o servidor trocam informações para validar quem eles afirmam ser, mas a senha do usuário nunca é acessível. Devido a esse recurso de segurança, não há maneira de o primeiro servidor autenticar você ao se conectar ao segundo servidor.
Usando a Delegação Kerberos
O Kerberos, como mencionado anteriormente, é uma maneira comum de configurar o PSRemoting. Sendo parte do onipresente Active Directory e já configurado por padrão, é extremamente comum. Embora, por si só, o Kerberos seja uma maneira adequada de autenticar o WinRM, ele não contorna o problema de duplo salto.
Para contornar o cenário de duplo salto, você pode usar um segundo tipo de autenticação conhecido como Delegação Kerberos. Embora existam muitas variedades de Delegação Kerberos, a única variedade capaz (e segura o suficiente) de se apresentar como uma alternativa ao CredSSP é chamada Restrita Delegação Kerberos, mais especificamente a Delegação Kerberos baseada em recursos.
A Delegação Kerberos baseada em recursos é uma forma de delegar tokens de autenticação Kerberos com base em recursos de domínio, como computadores, neste caso, restritos a uma lista específica de objetos Kerberos (Active Directory).
Para configurar essa delegação Kerberos, é necessário editar o objeto ADComputer do terceiro computador na cadeia. Por exemplo, se você estiver se conectando remotamente do ClienteA para o ServidorB e depois para o ServidorC, é preciso editar o objeto ADComputer para o ServidorC. No entanto, também é necessário saber qual será o ServidorB. Para este exemplo, execute o comando abaixo no PowerShell:
O uso da Delegação Kerberos baseada em recursos funciona para conexões remotas como… ou…, mas não funciona com o PSRemoting. Você não conseguirá se conectar a um terceiro computador ao se conectar a um computador via WinRM usando PSRemoting.
Configurar a Delegação Condicional Kerberos baseada em recursos é um comando PowerShell de uma linha usando o cmdlet Set-ADComputer. Se, por exemplo, você estiver conectado ao ServidorB a partir do ClienteA via PSRemoting e deseja se conectar ao ServidorC com…, você pode fazer isso executando o comando PowerShell abaixo.
O WinRm armazena em cache as conexões falhadas por 15 minutos. Devido a esse recurso, talvez você não consiga se conectar ao terceiro computador mesmo após configurar a Delegação Condicional Kerberos baseada em recursos. Para remediar, espere ou execute o comando
klist purge -LI 0x3e7no terceiro computador para limpar os tokens Kerberos falhados.
Como a Autenticação do PSRemoting sobre SSH Funciona
Embora a autenticação do WinRM seja o método mais comum de autenticação para o PSRemoting, a partir do PowerShell v6, você tem outra opção; SSH. Usar SSH como método de autenticação permite que você use o PSRemoting com o Linux.
O SSH, ao contrário do WinRM, requer algumas configurações adicionais tanto no cliente quanto no servidor, como configurar um cliente SSH no cliente Windows e …
Usar SSH para lidar com a autenticação significa que você está limitado aos tipos de autenticação que o SSH suporta. Isso reduz a lista com os principais sendo baseados em senha e baseados em chave pública.
Há outros tipos de autenticação suportados pelo SSH, mas geralmente são considerados menos seguros do que as opções baseadas em senha e chave pública, então vamos nos concentrar apenas nessas duas.
Autenticação por Senha
A maneira mais fácil de configurar a autenticação SSH com o PSRemoting é com autenticação baseada em senha. A autenticação baseada em senha permite que você forneça uma senha para se autenticar.
No processo de autenticação SSH, a senha é trocada após a conexão SSH ser estabelecida e a senha é criptografada durante a transmissão. Ao contrário de alguns métodos de autenticação usados pelo WinRM, como o Kerberos, este método de autenticação não envia a senha completa para o servidor.
Você pode comparar a autenticação de senha SSH ao método de autenticação Basic do WinRM usando um ouvinte HTTPS. A senha em si não é protegida de maneira significativa, mas toda a conexão, incluindo a senha, é criptografada, e o servidor é validado com base em um certificado.
Autenticação Baseada em Certificado (Certificate-Based Authentication)
Enquanto a autenticação baseada em senha é fácil de configurar e simples de usar, ela possui dois problemas.
- O primeiro é que não há maneira de autenticar de forma segura em um formato não assistido.
- A autenticação por senha ainda envia uma senha pela rede. Embora a senha seja criptografada dentro da conexão SSH, o servidor recebe a senha completa. Se o servidor for comprometido de alguma forma, isso poderia se tornar um problema de segurança.
A autenticação baseada em certificado, por outro lado, não envia nenhum dado sensível pela rede, como a senha. Em vez disso, o servidor possui uma cópia de uma chave pública, o cliente possui uma cópia da chave privada, e as negociações ocorrem no servidor.
A rough workflow goes as follows:
- Quando o cliente tenta se autenticar, ele envia o ID ou a impressão digital da chave pública para o servidor.
- Se o servidor tiver a chave pública listada como autorizada, ele responde com uma sequência criptografada com a chave pública.
- O cliente então descriptografa a sequência com a chave privada.
- A chave privada é então hashada com um ID de sessão.
- O ID de sessão é enviado de volta para o servidor, que então o compara com o hash gerado usando a string original e o ID de sessão.
- Se o hash do ID de sessão do cliente coincidir com o ID de sessão no servidor, o cliente se autentica e é autorizado a se conectar.
Tudo criptografado com a chave pública só pode ser descriptografado com uma chave privada associada. Tudo criptografado com a chave privada só pode ser descriptografado com a chave pública. O ID de sessão também é incluído para fornecer o que é chamado de Perfeita Sigilo Adiante (PFS).
O PFS fornece segurança caso a chave privada seja comprometida, o atacante não seria capaz de descriptografar todas as mensagens que foram trocadas. Um ID de sessão único significa que o segredo compartilhado usado para criptografar a comunicação é diferente para cada sessão.
Autenticação baseada em certificado com SSH, como o WinRM, requer esforço adicional para ser configurada, como gerar a chave privada/pública paga e autorizar a chave pública no servidor remoto.
Direitos do usuário necessários para conectar
Por padrão, dois grupos locais de usuários podem se conectar a um servidor remotamente usando o PSRemoting; Administradores e Usuários de Gerenciamento Remoto.
Brazil Portuguese
Enquanto você pode simplesmente adicionar contas de usuário ao grupo Administradores local em um servidor remoto, você sempre deve fornecer a menor quantidade possível de acesso. Se um usuário apenas precisa se conectar com PSRemoting a um computador remoto, pode adicionar a conta do usuário ao grupo Usuários de Gerenciamento Remoto, não ao grupo Administradores.
Para controlar ainda mais o acesso ao PSRemoting, você também pode usar um recurso chamado Administração Mínima (JEA). JEA permite que usuários não administradores executem apenas comandos específicos como administradores no modo de linguagem restrita do PowerShell.
Remoting Implícito vs. “Explícito”
Se você já usou PSRemoting antes, provavelmente está familiarizado com comandos como Invoke-Command, New-PSSession, Enter-PSSession, etc. Quando você executa esses comandos, fica claro que está se conectando a um computador remoto de alguma forma. Você está usando PSRemoting de forma explícita.
Ao executar comandos específicos do PSRemoting, você está os executando de forma explícita, mas você sabia que há outra maneira? Em vez de invocar Invoke-Command e outros cmdlets diretamente, você pode aproveitar o PSRemoting usando-o de forma implícita.
Implicit PSRemoting pode parecer que você está executando os comandos localmente dentro da sua sessão do PowerShell, mas na verdade eles estão sendo executados em uma máquina remota. Um bom exemplo disso é o uso de um módulo que não está instalado no seu sistema. Em vez de instalá-lo localmente, você pode exportar comandos de uma PSSession, o que permitirá que você os execute como se estivessem instalados localmente.
Na captura de tela abaixo, você pode ver que não tenho o comando Test-PendingReboot. Em seguida, eu me conectei a uma máquina remota e exportei esse comando.
Depois, se esse módulo for importado, eu posso executar o comando Test-PendingReboot. Isso é mostrado abaixo, mas você notará que ele exibe que o nome do computador na saída não é o nome do dispositivo de onde o PowerShell está sendo executado, mas sim o dispositivo de onde o comando foi importado.
