O PowerShell Remoting (PSRemoting) é uma das funcionalidades mais utilizadas em todo o PowerShell. Por quê? Porque é incrivelmente útil! 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 diversas tecnologias que fazem o PSRemoting funcionar. Este guia não abordará como usar o PSRemoting. Você verá muitas referências a muitos dos nossos guias práticos 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, SSH ou até mesmo psexec. É apenas uma maneira de executar comandos em computadores dentro do PowerShell.
O PSRemoting depende fortemente de um conceito chamado sessão. Uma sessão é um termo usado para descrever um shell remoto que executa comandos internamente. O processo para criar uma dessas sessões passa por muitas etapas nos bastidores.
Ao iniciar uma sessão de PSRemoting, as seguintes etapas aproximadas são executadas:
- 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 da web que é executado 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 por meio dos protocolos HTTP ou HTTPS, o processo de autenticação começa. Todos os detalhes de cada método de autenticação serão abordados posteriormente, mas por enquanto, saiba apenas que o cliente precisa enviar credenciais ao servidor de alguma forma.
- 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, ela está aberta para negócios. Neste ponto, o cliente pode começar a enviar informações para o servidor, com o servidor devolvendo qualquer saída necessária conhecida como serialização. Essa 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 em execução em qualquer computador com 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 forma 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; esta 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, se 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 realiza é a autenticação. A autenticação é uma das partes mais complicadas, mas essenciais, do PSRemoting.
Quando o PSRemoting foi introduzido pela primeira vez, 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; um 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, temos a autenticação básica. Esse tipo de autenticação é um padrão incorporado ao 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 destinatário.
Porque a autenticação básica apenas codifica o nome de usuário e senha e não os criptografa, é fácil interceptar as credenciais pela rede.
Não use a autenticação básica a menos que seja absolutamente necessário. Existem muitos outros métodos mais seguros que o WinRM pode autenticar!
Autenticação do Kerberos
Ambos o cliente e o servidor estão em um ambiente de Active Directory? Se sim, você já está usando autenticação do Kerberos em muitos de seus serviços de rede.
Quando o cliente do WinRM tenta se conectar a um ouvinte do WinRM usando o Kerberos:
- O servidor primeiro tenta obter uma chave de sessão ou um ticket de concessão de ticket para o cliente a partir 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 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 passe pelo servidor.
O Kerberos é um método de autenticação maduro e seguro e é o tipo de autenticação padrão quando um cliente e um servidor são membros de um domínio do Active Directory. No entanto, ele requer que tanto o cliente quanto o servidor estejam associados ao mesmo domínio do Active Directory ou que haja uma 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 sequência de caracteres.
- O cliente então criptografa a sequência de caracteres com um hash da senha do usuário.
- A sequência de caracteres criptografada é enviada de volta ao servidor, que envia o nome de usuário, a sequência original e a sequência criptografada para um controlador de domínio.
- O controlador de domínio então procura o hash da senha daquele usuário e repete o mesmo processo de criptografia na sequência para garantir que corresponda.
O NTLM é bom para validar o cliente, mas ao contrário do Kerberos, não valida o servidor. Isso abre várias possibilidades de ataques onde o servidor pode ser falsificado por um atacante.
Você pode melhorar a segurança do NTLM também validando o servidor com um certificado de autenticação do servidor e atribuindo-o a um ouvinte WinRM HTTPS. Nesta configuração, o cliente é autenticado com NTLM contra o controlador de domínio, e o servidor é autenticado com um certificado confiável. Embora esta configuração forneça autenticação tanto do cliente quanto do servidor, o protocolo NLTM usa uma cifra de criptografia mais antiga com um tamanho de chave desatualizado.
Por esses motivos, 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 mais incomuns para usar no WinRM é a autenticação Digest. NTLM e Digest são métodos de autenticação semelhantes. Como o NTLM, o Digest gera uma string única que é criptografada com o hash da senha do usuário. A senha então 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 usado. O MD5 tem várias vulnerabilidades conhecidas que o tornam inadequado para uso criptográfico.
Provedor de Suporte de Segurança de Credenciais (CredSSP)
Embora pudéssemos entrar nos pormenores do CredSSP, não é necessário. Por quê? Porque, quando se trata de PSRemoting e WinRM, o CredSSP é implementado geralmente por um motivo, o “problema do segundo salto”, que você aprenderá abaixo.
Quando configurado para autenticação CredSSP, tanto o cliente quanto o servidor WinRM utilizam a autenticação Negociar para autenticar tanto o usuário quanto o cliente. Mas, uma vez concluído, a senha do usuário é enviada para o servidor.
Como a senha é enviada após o processo de autenticação ter sido concluído, ela está 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 plenamente no servidor ao qual se conectou com a senha do usuário.
Autenticação Baseada em Certificado
Argumentavelmente, o método mais seguro de autenticação a ser usado com PSRemoting é a autenticação baseada em certificado. Neste método de autenticação, ocorre uma troca típica de chaves com uma chave privada e pública no cliente e um servidor validando o certificado.
O 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, sendo assim uma forma muito segura de autenticação
. Embora seja a forma mais segura, a autenticação baseada em certificado 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 de 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.
Você não pode usar um usuário de domínio para autenticar com certificados, mesmo que o cliente e o servidor façam parte do Active Directory.
Padrões de Autenticação do Sistema Operacional Windows
Agora que você viu que existem muitas opções de autenticação disponíveis, como saber quais estão disponíveis por padrão? Abaixo, você verá uma tabela com duas colunas indicando se o cliente WinRM, por padrão, está habilitado e se esse tipo específico de autenticação está habilitado por padrão.
Todos os tipos de autenticação mencionados são configuráveis, mas usar a tabela abaixo lhe dará uma boa ideia do que você 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 Segundo Salto ou Problema do Duplo Salto
Um dos maiores problemas com o PSRemoting é conhecido como o “problema do segundo salto” ou “duplo salto”. Esta situação ocorre quando você se conecta a um sistema remoto através do PSRemoting e, em seguida, precisa se conectar a outro computador remoto.
Esta 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. Quando você tenta se conectar ao segundo computador a partir do servidor da primeira conexão, o servidor final não tem como validar a identidade do usuário.
Você pode resolver o problema do duplo salto de algumas maneiras diferentes, seja através do uso do CredSSP ou da Delegação do Kerberos.
Usando o CredSSP
A maneira mais comum de contornar o problema do duplo salto é usando o CredSSP. A autenticação do CredSSP contorna essa situação armazenando uma credencial de usuário no primeiro servidor remoto, que o servidor convertido em cliente pode então passar para o segundo servidor remoto.
Há um porém ao usar o CredSSP. A credencial de usuário armazenada no primeiro servidor remoto pode ser armazenada em texto simples, introduzindo assim uma preocupação óbvia de segurança. Em sistemas operacionais mais recentes, um hash da senha e do Ticket de Concessão de Tíquete do Kerberos (TGT) são utilizados. Estes podem ser usados juntos para autenticar como o usuário em qualquer lugar na rede, assim como uma senha em texto simples, mas isso reduz um pouco o risco.
Com a Negociação, o cliente e o servidor trocam informações para validar quem eles dizem ser, mas a senha do usuário nunca é acessível. Devido a esse recurso de segurança, não há maneira de o 1º servidor autenticar você quando se conecta ao 2º servidor.
Usando a Delegação Kerberos
O Kerberos, como mencionado anteriormente, é uma maneira comum de configurar o PSRemoting. Fazendo 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 double-hop.
Para contornar o cenário de double-hop, 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 de Delegação Kerberos Constrained mais especificamente Delegação Constrained baseada em recursos.
A Delegação Kerberos Constrained baseada em recursos é uma forma de delegar tokens de autenticação Kerberos com base em recursos de domínio, como computadores, neste caso, que estão restritos a uma lista específica de objetos Kerberos (Active Directory).
Para configurar essa delegação do Kerberos, você precisa editar o objeto ADComputer do terceiro computador na cadeia. Por exemplo, se você estiver se conectando remotamente de ClientA para ServerB e, em seguida, para ServerC, é necessário editar o objeto ADComputer para ServerC. No entanto, também é necessário saber qual será o ServerB. Para este exemplo, execute o comando abaixo no PowerShell:
O uso da Delegação do Kerberos baseada em recursos funciona para conexões remotas como …. ou …, mas não funcionará com o PSRemoting. Você não conseguirá se conectar a um terceiro computador ao se conectar a um computador via WinRM usando PSRemoting.
A configuração da Delegação Restrita do Kerberos baseada em recursos é um comando PowerShell de uma linha usando o cmdlet Set-ADComputer. Se, por exemplo, você estiver conectado a ServerB a partir de ClientA via PSRemoting e quiser se conectar a ServerC com …, você pode fazer isso executando o comando PowerShell abaixo.
O WinRm armazena em cache conexões falhadas por 15 minutos. Devido a esse recurso, você pode não conseguir se conectar ao terceiro computador mesmo depois de configurar a Delegação Restrita do Kerberos baseada em recursos. Para remediar, aguarde ou execute o comando
klist purge -LI 0x3e7no terceiro computador para purgar os tokens de 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 maneira; SSH. Usar o SSH como método de autenticação permite que você use o PSRemoting com o Linux.
O SSH, ao contrário do WinRm, requer alguma configuração adicional 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 dois principais sendo baseados em senha e baseados em chave pública.
Existem outros tipos de autenticação suportados pelo SSH, mas geralmente são considerados menos seguros do que as opções baseadas em senha e em 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 PSRemoting é com autenticação baseada em senha. A autenticação baseada em senha permite que você forneça uma senha para se validar.
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 de certa forma a autenticação de senha SSH ao método de autenticação básica 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
Enquanto a autenticação baseada em senha é fácil de configurar e direta de usar, ela apresenta 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 tem uma cópia de uma chave pública, o cliente tem uma cópia da chave privada, e as negociações acontecem no servidor.
A rough workflow goes as follows:
- Quando o cliente tenta autenticar, ele envia o ID ou 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 string criptografada com a chave pública.
- O cliente então descriptografa a string com a chave privada.
- A chave privada é então criptografada com um ID de sessão.
- O ID da sessão é enviado de volta ao servidor, que o compara com o hash gerado usando a string original e o ID da sessão.
- Se o hash do ID da sessão do cliente e o ID da sessão no servidor coincidirem, o cliente se autentica e tem permissão para se conectar.
Qualquer coisa criptografada com a chave pública só pode ser descriptografada com uma chave privada associada. Qualquer coisa criptografada com a chave privada só pode ser descriptografada com a chave pública. O ID da sessão também é incluído para fornecer o que é chamado de Segredo Perfeito para o Futuro (PFS).
O PFS fornece segurança se a chave privada for 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.
A autenticação baseada em certificados com SSH, como o WinRm, requer um esforço adicional para ser configurado, 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 PSRemoting; Administradores e Usuários de Gerenciamento Remoto.
Enquanto você pode simplesmente adicionar contas de usuário ao grupo Administradores local em um servidor remoto, você sempre deve fornecer a menor quantidade de acesso possível. Se um usuário apenas precisa se conectar com o PSRemoting a um computador remoto, pode adicionar a conta de 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 – Just Enough Administration). 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 o 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 o PSRemoting de forma explícita.
Ao executar comandos específicos do PSRemoting, você está explicitamente executando esses comandos, 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.
O PSRemoting implícito 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 é usar 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 eu não tenho o comando Test-PendingReboot. Então, eu me conectei a uma máquina remota e exportei esse comando.
Em seguida, se esse módulo for importado, eu posso executar o comando Test-PendingReboot. Isso é mostrado abaixo, mas você notará que ele mostra 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 do qual o comando foi importado.
