Como controlar o teu PC desde o teu teléfono móbil usando o control remoto de PowerShell

Pode que xa automatices moitas tarefas con PowerShell localmente, pero onde as fas realmente? A conexión remota de PowerShell marca a diferenza É cando executas comandos en máquinas remotas, xa sexan unhas poucas ou centos, de forma interactiva ou en paralelo. Esta tecnoloxía, dispoñible desde Windows PowerShell 2.0 e mellorada desde a versión 3.0, baséase en WS-Management (WinRM) e converte PowerShell nun canal de xestión remota robusto, escalable e seguro.

En primeiro lugar, é importante comprender dúas ideas clave: os cmdlets con -Parámetro Nome do Equipo (por exemplo, Get-Process ou Get-Service) non son a ruta a longo prazo recomendada por Microsoft e as accións remotas de PowerShell non funcionan como un «hack». De feito, aplica a autenticación mutua, rexistros de auditoría e respecta os teus permisos habituais, sen almacenar credenciais nin executar maxicamente nada con superprivilexios.

Que é o control remoto de PowerShell e por que usalo?

con Control remoto de PowerShell podes executar case calquera comando de forma remota que podería iniciar nunha sesión local, desde a consulta de servizos ata a implementación de configuracións, e facelo en centos de ordenadores á vez. A diferenza dos cmdlets que aceptan -ComputerName (moitos usan DCOM/RPC), a conexión remota viaxa a través de WS-Man (HTTP/HTTPS), que é máis compatible co firewall, permite o paralelismo e descarga o traballo ao servidor remoto, non ao cliente.

Isto tradúcese en tres vantaxes prácticas: mellor rendemento en execucións masivas, menos fricción nas redes con regras restritivas e un modelo de seguranza coherente con Kerberos/HTTPS. Ademais, ao non depender de cada cmdlet para implementar o seu propio control remoto, o control remoto Funciona para calquera guión ou rol que está dispoñible no destino.

Por defecto, os servidores Windows recentes inclúen a función remota activada; en Windows 10/11 o activas cun único cmdlet. E si, podes usar credenciais alternativas, sesións persistentes, puntos finais personalizados e moito máis.

Nota: O uso remoto non é sinónimo de abrir todo. Por defecto, só administradores Poden conectarse e as accións execútanse baixo a súa identidade. Se precisas unha delegación detallada, os puntos finais personalizados permítenche expoñer só os comandos esenciais.

Como funciona no interior: WinRM, WS-Man e portos

A comunicación remota de PowerShell funciona nun modelo cliente-servidor. O cliente envía solicitudes de WS-Management a través de HTTP (5985/TCP) ou HTTPS (5986/TCP)No destino, o servizo de xestión remota de Windows (WinRM) escoita, resolve o punto final (configuración da sesión) e hospeda a sesión de PowerShell en segundo plano (proceso wsmprovhost.exe). devolver resultados serializados ao cliente en XML mediante SOAP.

A primeira vez que se activa a conexión remota, configúranse os escoitadores, ábrese a excepción de firewall axeitada e créanse as configuracións de sesión. Desde PowerShell 6+, coexisten varias edicións e Activar-PSRemoting Rexistra puntos finais con nomes que reflicten a versión (por exemplo, PowerShell.7 e PowerShell.7.xy).

Se só permites HTTPS no teu entorno, podes crear un oínte seguro cun certificado emitido por unha CA de confianza (recomendado). Como alternativa, outra alternativa é usar TrustedHosts dun xeito limitado e consciente do risco, para escenarios de grupos de traballo ou ordenadores que non son de dominio.

Ten en conta que a xestión remota de Powershell pode coexistir con cmdlets con -NomeDoEquipo, pero Microsoft impulsa WS-Man como o método estándar e a proba de futuro para a administración remota.

Activación da conexión remota de PowerShell e parámetros útiles

En Windows, só tes que abrir PowerShell como administrador e executar Activar-PSRemotingO sistema inicia WinRM, configura o inicio automático, activa o escoitador e crea as regras de cortafuegos axeitadas. En clientes cun perfil de rede pública, podes permitir isto deliberadamente con -Omitir comprobación de perfís de rede (e logo reforzar con regras específicas):

Enable-PSRemoting
Enable-PSRemoting -Force
Enable-PSRemoting -SkipNetworkProfileCheck -Force

 

A sintaxe tamén permite, -Confirmar y -E se para o control de cambios. Lembre: Só está dispoñible en Windowse debes executar a consola elevada. As regras creadas difiren entre as edicións de servidor e cliente, especialmente en redes públicas, onde por defecto están limitadas á subrede local a menos que amplíes o alcance (por exemplo, con Set-NetFirewallRule).

Para listar as configuracións de sesión xa gravadas e confirmar que todo está listo, use Get-PSSessionConfigurationSe aparecen os extremos de PowerShell.x e Workflow, o marco de traballo remoto está operativo.

Modos de uso: 1 a 1, 1 a moitos e sesións persistentes

Cando precise unha consola interactiva nun só ordenador, consulte Enter-PSSessionAparecerá a solicitude e todo o que executes irá ao servidor remoto. Podes reutilizar as credenciais con Get-Credential para evitar ter que introducilas de novo constantemente:

$cred = Get-Credential
Enter-PSSession -ComputerName dc01 -Credential $cred
Exit-PSSession

Se o que buscas é enviar comandos a varios ordenadores á vez, a ferramenta é Invoke-Command cun bloque de script. Por defecto, lanza ata 32 conexións simultáneas (axustables con -ThrottleLimit). Os resultados devólvense como obxectos deserializados (sen métodos "en directo"):

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service -Name W32Time } -Credential $cred

Necesitas invocar un método como .Stop() ou .Start()? Faio. dentro do bloque de script no contexto remoto, non no obxecto deserializado local, e punto final. Se existe un cmdlet equivalente (Stop-Service/Start-Service), normalmente é preferible usalo para maior claridade.

Para evitar o custo de iniciar e finalizar sesións en cada chamada, crea un Sesión PS persistente e reutilízao en varias invocacións. Usa New-PSSession para crear a conexión e usa Invoke-Command-Session para reutilizar o túnel. Non esquezas pechalo con Remove-PSSession cando remates.

Serialización, límites e boas prácticas

Un detalle importante: ao viaxar, os obxectos "aplananse" e chegan como instantáneas deserializadas, con propiedades pero sen métodos. Isto é deliberado e aforra ancho de banda, pero significa que non podes usar membros que executen lóxica (como .Kill()) na copia local. A solución é obvia: invocar eses métodos. remotamente e se só precisa certos campos, filtre con Select-Object para enviar menos datos.

Nos scripts, evita Enter-PSSession (pensado para uso interactivo) e usa Invoke-Command con bloques de script. Se prevés varias chamadas ou necesitas preservar o estado (variables, módulos importados), usar sesións persistentes e, se é o caso, desconécteos/reconécteos con Disconnect-PSSession/Connect-PSSession en PowerShell 3.0+.

Autenticación, HTTPS e escenarios fóra de dominio

Nun dominio, a autenticación nativa é Kerberos E todo flúe. Cando o dispositivo non pode verificar o nome do servidor ou se conecta a un IP ou alias CNAME, precisa unha destas dúas opcións: 1) Listener HTTPS con certificado emitido por unha CA na que confíes ou 2) engade o destino (nome ou IP) a TrustedHosts e usar credenciaisA segunda opción desactiva a autenticación mutua para ese host, polo que reduce o alcance ao mínimo necesario.

A configuración dun escoitador HTTPS require un certificado (idealmente da túa PKI ou dunha CA pública), instalado no almacén do equipo e vinculado a WinRM. Despois, ábrese o porto 5986/TCP no firewall e, desde o cliente, utilízase. -Usar SSL en cmdlets remotos. Para a autenticación de certificados de cliente, pode mapear un certificado a unha conta local e conectarse con -Impresión dixital do certificado (Enter-PSSession non acepta isto directamente; crea primeiro a sesión con New-PSSession.)

O segundo salto e a delegación de credenciais

O famoso "dobre salto" aparece cando, despois de conectarse a un servidor, necesitas que ese servidor acceda a un terceiro recurso no teu nome (por exemplo, unha compartición SMB). Hai dúas maneiras de permitir isto: CredSSP e a delegación Kerberos restrinxida baseada en recursos.

con CredSSP Permites que o cliente e o intermediario deleguen explicitamente as credenciais e defines unha política (GPO) para permitir a delegación a ordenadores específicos. É rápido de configurar, pero menos seguro porque as credenciais viaxan en texto sen cifrar dentro do túnel cifrado. Limita sempre as orixes e os destinos.

A alternativa preferida no dominio é a delegación Kerberos restrinxida (delegación restrinxida baseada en recursos) no AD moderno. Isto permite que o punto final dependa da recepción da delegación do punto intermedio para servizos específicos, evitando expoñer a túa identidade na conexión inicial. Require controladores de dominio recentes e un RSAT actualizado.

Puntos finais personalizados (configuracións de sesión)

Unha das xoias do teletraballo é poder rexistrar puntos de conexión con capacidades e límites adaptadosPrimeiro xérase un ficheiro con New-PSSessionConfigurationFile (módulos para precargar, funcións visibles, alias, ExecutionPolicy, LanguageMode, etc.) e, a seguir, rexístrase con Register-PSSessionConfiguration, onde se poden definir Executar como credencial e permisos (SDDL ou interface GUI con -ShowSecurityDescriptorUI).

Para unha delegación segura, expoña só o necesario con -VisibleCmdlets/-VisibleFunctions e desactive os scripts gratuítos se é apropiado con Modo de idioma Idioma restrinxido ou NoLanguage. Se deixas FullLanguage, alguén podería usar un bloque de script para invocar comandos non expostos, o que, combinado con RunAs, sería un buratoDeseña estes puntos finais cun peite fino e documenta o seu alcance.

Dominios, GPO e software de grupo

En AD podes implementar a xestión remota de Powershell a escala con GPO: permite a configuración automática dos escoitadores de WinRM, configurar o servizo en Automáticoe crea a excepción do cortafuegos. Lembra que os GPO cambian a configuración, pero non sempre activan o servizo ao instante; ás veces cómpre reiniciar ou forzar unha actualización de gp.

En grupos de traballo (que non son de dominio), configure a conexión remota con Activar-PSRemoting, configure TrustedHosts no cliente (winrm set winrm/config/client @{TrustedHosts=»host1,host2″}) e use credenciais locais. Para HTTPS, pode montar certificados autoasinados, aínda que se recomenda usar unha CA de confianza e validar o nome que usarás en -NomeDoEquipo no certificado (coincidencia CN/SAN).

Cmdlets clave e sintaxe

Un puñado de comandos cobren a 90 % dos escenarios diariosPara activar/desactivar:

Enable-PSRemoting    
Disable-PSRemoting

Sesión interactiva 1 a 1 e saída:

Enter-PSSession -ComputerName SEC504STUDENT 
Exit-PSSession

1 a moitos, con paralelismo e credenciais:

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service W32Time } -Credential $cred

Sesións persistentes e reutilizar:

$s = New-PSSession -ComputerName localhost -ConfigurationName PowerShell.7
Invoke-Command -Session $s -ScriptBlock { $PSVersionTable }
Remove-PSSession $s

Probas e WinRM Útil:

Test-WSMan -ComputerName host
winrm get winrm/config
winrm enumerate winrm/config/listener
winrm quickconfig -transport:https

Notas prácticas sobre cortafuegos, rede e portos

Abra 5985/TCP para HTTP e 5986/TCP para HTTPS no computador de destino e en calquera cortafuegos intermedioNos clientes de Windows, Enable-PSRemoting crea regras para perfís de dominio e privados; para perfís públicos, limítase á subrede local a menos que modifiques o ámbito con Set-NetFirewallRule -RemoteAddress Any (un valor que podes avaliar en función do teu risco).

Se empregas integracións SOAR/SIEM que executan comandos remotos (por exemplo, desde XSOAR), asegúrate de que o servidor teña Resolución DNS cos hosts, conectividade a 5985/5986 e credenciais con permisos locais suficientes. Nalgúns casos, a autenticación NTLM/Basic pode requirir axuste (por exemplo, usar un usuario local en Basic con SSL).

Parámetros de activación de PSRemoting (resumo operativo)

-Confirmar pide confirmación antes de executar; -Forzar ignora os avisos e facer os cambios necesarios; -SkipNetworkProfileCheck activa a conexión remota en redes de clientes públicas (limitado por defecto á subrede local); -WhatIf móstrache o que sucedería sen aplicar os cambios. Ademais, como calquera cmdlet estándar, admite parámetros comúns (-Verbose, -ErroAction, etc.).

Lembra que "Activar" non crea escoitadores nin certificados HTTPS por ti; se necesitas cifrado de extremo a extremo desde o principio e autenticación baseada en certificados, configura o escoitador HTTPS e valida CN/SAN co nome que usarás en -NomeDoEquipo.

Comandos remotos útiles de WinRM e PowerShell

Algúns artigos esenciais de noite Para o día a día:

winrm get winrm/config
winrm enumerate winrm/config/listener
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress Any
Test-WSMan -ComputerName host -Authentication Default -Credential (Get-Credential)
New-PSSession -ComputerName host 
Enter-PSSession -ComputerName host 
Enable-PSRemoting -SkipNetworkProfileCheck -Force

Ao xestionar Windows a escala, a xestión remota permíteche pasar dunha abordaxe "de ordenador a ordenador" a unha declarativa e segura. Ao combinar sesións persistentes, autenticación forte (Kerberos/HTTPS), puntos finais restrinxidos e rastrexos claros para diagnósticos, gañas velocidade e control sen sacrificar a seguridade nin a auditoría. Se tamén estandarizas a activación de GPO e dominas os casos especiais (TrustedHosts, dobre salto, certificados), terás unha plataforma remota sólida para as operacións diarias e a resposta a incidentes.