Cómo controlar tu PC desde el móvil usando PowerShell Remoting

Quizá ya automatizas muchas tareas con PowerShell de forma local, pero donde realmente PowerShell Remoting marca la diferencia es cuando ejecutas comandos en máquinas remotas, sean pocas o cientos, de manera interactiva o en paralelo. Esta tecnología, disponible desde Windows PowerShell 2.0 y potenciada a partir de la 3.0, se basa en WS-Management (WinRM) y convierte a PowerShell en un canal de administración remota robusto, escalable y seguro.

Antes de nada, conviene entender dos ideas clave: los cmdlets con parámetro -ComputerName (por ejemplo, Get-Process o Get-Service) no son el camino recomendado a largo plazo por Microsoft, y PowerShell Remoting no funciona como un “hack”. De hecho, impone autenticación mutua, registra auditoría y respeta tus permisos de siempre, sin almacenar credenciales ni ejecutar nada con súper privilegios por arte de magia.

Qué es PowerShell Remoting y por qué usarlo

Con PowerShell Remoting puedes ejecutar en remoto casi cualquier comando que podrías lanzar en una sesión local, desde consultar servicios hasta desplegar configuraciones, y hacerlo en cientos de equipos a la vez. A diferencia de los cmdlets que aceptan -ComputerName (muchos usan DCOM/RPC), Remoting viaja por WS-Man (HTTP/HTTPS), que es más amigable con cortafuegos, permite paralelismo y descarga el trabajo en el host remoto, no en el cliente.

Esto se traduce en tres ventajas prácticas: mejor rendimiento en ejecuciones masivas, menos fricción en redes con reglas restrictivas y un modelo de seguridad coherente con Kerberos/HTTPS. Además, al no depender de que cada cmdlet implemente su propia remota, Remoting sirve para cualquier guion o función que esté disponible en el destino.

Por defecto, Windows Server recientes traen Remoting habilitado; en Windows 10/11 lo activas con un solo cmdlet. Y sí, puedes usar credenciales alternativas, sesiones persistentes, puntos de conexión personalizados y más.

Ojo: Remoting no es sinónimo de abrir todo. Por defecto, solo los administradores pueden conectarse, y las acciones se ejecutan con su identidad. Si necesitas delegación fina, los endpoints personalizados te permiten exponer solo los comandos imprescindibles.

Cómo funciona por dentro: WinRM, WS-Man y puertos

PowerShell Remoting funciona en un modelo cliente-servidor. El cliente envía peticiones WS-Management por HTTP (5985/TCP) o HTTPS (5986/TCP). En el destino, el servicio Windows Remote Management (WinRM) escucha, resuelve el punto de conexión (configuración de sesión) y hospeda la sesión de PowerShell en segundo plano (proceso wsmprovhost.exe), devolviendo al cliente resultados serializados en XML vía SOAP.

La primera vez que habilitas Remoting, se configuran los listeners, se abre la excepción de firewall adecuada y se crean configuraciones de sesión. Desde PowerShell 6+ conviven varias ediciones, y Enable-PSRemoting registra endpoints con nombres que reflejan la versión (por ejemplo, PowerShell.7 y PowerShell.7.x.y).

Si en tu entorno solo permites HTTPS, puedes crear un listener seguro con un certificado emitido por una CA confiable (recomendado). Si no, otra alternativa es usar TrustedHosts de forma limitada y consciente de los riesgos, para escenarios de grupos de trabajo o equipos fuera de dominio.

Ten en cuenta que Powershell Remoting puede coexistir con cmdlets con -ComputerName, pero Microsoft empuja WS-Man como la vía estándar y de futuro para administración remota.

Habilitar PowerShell Remoting y parámetros útiles

En Windows, basta con abrir PowerShell como administrador y ejecutar Enable-PSRemoting. El sistema inicia WinRM, configura el inicio automático, habilita el listener y crea las reglas de firewall adecuadas. En clientes con perfil de red pública, puedes permitirlo conscientemente con -SkipNetworkProfileCheck (y reforzar después con reglas específicas):

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

 

La sintaxis admite, además, -Confirm y -WhatIf para control de cambios. Recuerda: solo está disponible en Windows, y debes ejecutar la consola elevada. Las reglas creadas difieren entre ediciones Server y Client, especialmente en redes públicas, donde por defecto se limita a la subred local salvo que tú amplíes el alcance (por ejemplo, con Set-NetFirewallRule).

Para listar configuraciones de sesión ya registradas y confirmar que todo quedó listo, usa Get-PSSessionConfiguration. Si aparecen endpoints PowerShell.x y, en su caso, Workflow, el esqueleto de Remoting está operativo.

Modos de uso: 1 a 1, 1 a muchos y sesiones persistentes

Cuando necesitas una consola interactiva en un único equipo, recurre a Enter-PSSession. El prompt mostrará y todo lo que ejecutes irá al host remoto. Puedes reutilizar credenciales con Get-Credential para no reintroducirlas constantemente:

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

Si lo que buscas es enviar comandos a varios equipos a la vez, la herramienta es Invoke-Command con un scriptblock. Por defecto lanza hasta 32 conexiones concurrentes (ajustable con -ThrottleLimit). Los resultados vuelven como objetos deserializados (sin métodos “vivos”):

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

¿Que necesitas invocar un método como .Stop() o .Start()? Hazlo dentro del scriptblock en el contexto remoto, no en el objeto deserializado local, y listo. Si hay cmdlet equivalente (Stop-Service/Start-Service), suele ser preferible emplearlo por claridad.

Para evitar el coste de levantar y tumbar sesiones en cada llamada, crea una PSSession persistente y reutilízala en varias invocaciones. Con New-PSSession generas la conexión, y con Invoke-Command -Session reaprovechas el túnel. No olvides cerrar con Remove-PSSession al terminar.

Serialización, límites y buenas prácticas

Un detalle importante: al viajar, los objetos «+se aplanan» y llegan como instantáneas deserializadas, con propiedades pero sin métodos. Esto es deliberado y ahorra ancho de banda, pero implica que no puedes usar miembros que ejecutan lógica (como .Kill()) en la copia local. La solución es obvia: invoca esos métodos en remoto y, si solo necesitas ciertos campos, filtra con Select-Object para enviar menos datos.

En scripts, evita Enter-PSSession (pensado para uso interactivo) y usa Invoke-Command con scriptblocks. Si prevés múltiples llamadas o necesitas conservar estado (variables, módulos importados), usa sesiones persistentes y, si toca, desconéctalas/reconéctalas con Disconnect-PSSession/Connect-PSSession en PowerShell 3.0+.

Autenticación, HTTPS y escenarios fuera de dominio

En un dominio, la autenticación nativa es Kerberos y todo fluye. Cuando el equipo no puede verificar el nombre del servidor, o conectas a una IP o alias CNAME, necesitas una de estas dos vías: 1) Listener HTTPS con certificado emitido por una CA en la que confías, o 2) añadir el destino (nombre o IP) a TrustedHosts y usar credenciales. La segunda opción desactiva la autenticación mutua para ese host, así que reduce el alcance a lo mínimo necesario.

Configurar un listener HTTPS requiere un certificado (idealmente de tu PKI o una CA pública), instalado en el almacén de equipo y enlazado a WinRM. Después se abre el puerto 5986/TCP en el firewall y, desde el cliente, se emplea -UseSSL en los cmdlets remotos. Para autenticación por certificado de cliente, puedes mapear un cert a una cuenta local y conectarte con -CertificateThumbprint (Enter-PSSession no lo acepta directamente; crea primero la sesión con New-PSSession).

El segundo salto y delegación de credenciales

El famoso “doble salto” aparece cuando, tras conectarte a un servidor, necesitas que ese servidor acceda a un tercer recurso en tu nombre (por ejemplo, un recurso compartido SMB). Para permitirlo existen dos enfoques: CredSSP y la delegación Kerberos restringida basada en recursos.

Con CredSSP habilitas al cliente y al intermediario para delegar credenciales explícitamente, y ajustas política (GPO) para permitir la delegación a determinados equipos. Es rápido de configurar, pero menos seguro porque las credenciales viajan en claro dentro del túnel cifrado. Siempre acota orígenes y destinos.

La alternativa preferida en dominio es la delegación Kerberos restringida (resource-based constrained delegation) en AD moderno. Con ello, el equipo “del final” confía en recibir delegación desde el intermedio para servicios concretos, evitando exponer tu identidad en la conexión inicial. Requiere controladores de dominio recientes y RSAT actualizado.

Endpoints personalizados (configuraciones de sesión)

Una de las joyas de Remoting es poder registrar puntos de conexión con capacidades y límites a medida. Primero generas un archivo con New-PSSessionConfigurationFile (módulos a precargar, funciones visibles, alias, ExecutionPolicy, LanguageMode, etc.), y después lo registras con Register-PSSessionConfiguration, donde puedes establecer RunAsCredential y permisos (SDDL o interfaz GUI con -ShowSecurityDescriptorUI).

Para delegación segura, expón solo lo necesario con -VisibleCmdlets/-VisibleFunctions y desactiva scripting libre si procede con LanguageMode RestrictedLanguage o NoLanguage. Si dejas FullLanguage, alguien podría usar un bloque de script para invocar comandos no expuestos, lo que, combinado con RunAs, sería un agujero. Diseña estos endpoints con lupa y documenta su alcance.

Dominios, GPO y trabajo en grupo

En AD puedes desplegar Powershell Remoting a escala con GPO: permitir la configuración automática de listeners de WinRM, ajustar el servicio a Automático, y crear la excepción de firewall. Recuerda que GPO cambia configuración, pero no siempre enciende el servicio al instante; a veces toca reiniciar o forzar gpupdate.

En grupos de trabajo (sin dominio), configura Remoting con Enable-PSRemoting, ajusta TrustedHosts en el cliente (winrm set winrm/config/client @{TrustedHosts=»host1,host2″}) y usa credenciales locales. Para HTTPS, puedes montar certificados autofirmados, aunque lo recomendable es usar una CA confiable y validar el nombre que usarás en -ComputerName en el certificado (coincidencia CN/SAN).

Cmdlets y sintaxis clave

Un puñado de comandos cubren el 90% de escenarios diarios. Para activar/desactivar:

Enable-PSRemoting    
Disable-PSRemoting

Sesión interactiva 1 a 1 y salida:

Enter-PSSession -ComputerName SEC504STUDENT 
Exit-PSSession

1 a muchos, con paralelismo y credenciales:

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

Sesiones persistentes y reutilización:

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

Pruebas y WinRM útil:

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

Notas prácticas sobre firewall, red y puertos

Abre 5985/TCP para HTTP y 5986/TCP para HTTPS en el equipo de destino y en cualquier firewall intermedio. En clientes Windows, Enable-PSRemoting crea reglas para perfiles de dominio y privado; para público limita a la subred local a menos que modifiques el alcance con Set-NetFirewallRule -RemoteAddress Any (valor a evaluar en tu riesgo).

Si usas integraciones SOAR/SIEM que ejecutan comandos remotos (por ejemplo, desde XSOAR), asegúrate de que el servidor tenga resolución DNS hacia los hosts, conectividad a 5985/5986 y credenciales con permisos locales suficientes. En algunos casos, la autenticación NTLM/Básica puede requerir ajustes (por ejemplo, usar usuario local en Basic con SSL).

Parámetros de Enable-PSRemoting (resumen operativo)

-Confirm pide confirmación antes de ejecutar; -Force omite los avisos y realiza los cambios necesarios; -SkipNetworkProfileCheck habilita Remoting en redes públicas de clientes (limitando por defecto a subred local); -WhatIf te muestra qué pasaría sin aplicar cambios. Además, como cualquier cmdlet estándar, soporta parámetros comunes (-Verbose, -ErrorAction, etc.).

Recuerda que “Enable” no crea listeners HTTPS ni certificados por ti; si necesitas cifrado end-to-end desde el inicio y autenticación basada en certificados, configura el listener HTTPS y valida CN/SAN contra el nombre que usarás en -ComputerName.

Comandos útiles de WinRM y PowerShell Remoting

Algunos imprescindibles de cabecera para el 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

A la hora de administrar Windows a escala, Remoting te permite pasar de “ir equipo a equipo” a un enfoque declarativo y seguro. Combinando sesiones persistentes, autenticación robusta (Kerberos/HTTPS), endpoints restringidos y trazas claras para diagnóstico, ganas velocidad y control sin sacrificar seguridad ni auditoría. Si además estandarizas la activación vía GPO y dominas los casos especiales (TrustedHosts, doble salto, certificados), tendrás una plataforma remota sólida para operación diaria y respuesta ante incidentes.