El PowerShell Remoting (PSRemoting) es una de las características más utilizadas en todo PowerShell. ¿Por qué? ¡Porque es increíblemente útil! Con un solo comando, puedes conectarte de manera transparente a una o miles de computadoras remotas y ejecutar comandos.
En esta Guía Definitiva, profundizarás en PSRemoting. Aprenderás qué es, cómo funciona y todas las diversas tecnologías que hacen que PSRemoting funcione. Esta guía no cubrirá cómo usar PSRemoting. Verás muchas referencias a muchos de nuestros tutoriales a lo largo de esta guía.
Cómo Funciona PSRemoting
En pocas palabras, PSRemoting te permite ejecutar comandos en computadoras remotas como si estuvieras frente a ellas. PSRemoting proporciona un conjunto de características que conecta y autentica a un usuario, ejecuta comandos remotos y devuelve cualquier salida de ese comando a la computadora local.
Piensa en PSRemoting como telnet o SSH, o incluso psexec. Es simplemente una forma de ejecutar comandos en computadoras dentro de PowerShell.
PSRemoting depende en gran medida de un concepto llamado sesión. Una sesión es un término utilizado para describir una shell remota que ejecuta comandos internamente. El proceso para crear una de estas sesiones pasa por muchos pasos en segundo plano.
Cuando inicias una sesión de PSRemoting, se llevan a cabo los siguientes pasos aproximados:
- El cliente intenta conectarse al servidor de destino en un escucha WinRM (más sobre los escuchas WinRM a continuación). Un escucha WinRM es un pequeño servicio web que se ejecuta en el servidor de destino. WinRM es la implementación de Microsoft de un estándar llamado WSMan. WSMan es un estándar abierto creado con muchas otras grandes empresas tecnológicas de la época, como Dell, Intel y Sun Microsystems.
- Cuando el cliente se conecta al escucha a través del protocolo HTTP o HTTPS, comienza el proceso de autenticación. Todos los detalles de cada método de autenticación se cubrirán más adelante, pero por ahora, solo sepa que el cliente debe pasar credenciales al servidor de alguna manera.
- Después de que el cliente se conecta y se autentica en el servidor, PSRemoting crea una sesión.
- Una vez que PSRemoting crea la sesión, está lista para funcionar. En este punto, el cliente puede comenzar a enviar información al servidor, con el servidor devolviendo cualquier salida necesaria conocida como serialización. Esta comunicación suele estar cifrada.
Escuchas WinRM: Disponibles para conexión
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.
Puedes descubrir todos los escuchas WinRm en ejecución en cualquier computadora con Windows utilizando el comando winrm a continuación.
Los escuchas WinRm tienen algunos componentes importantes. Tienen:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- El tipo de transporte – Cada oyente de WinRM necesita una manera de comunicarse con el cliente; lo hacen a través de un transporte utilizando HTTP o HTTPS.
- Una huella digital de certificado opcional – Cuando un oyente de WinRM utiliza HTTPS para el transporte, debe saber qué clave privada utilizar para autenticar al cliente; esta clave se encuentra usando una huella digital de certificado.
Utiliza un oyente HTTPS cuando sea posible. Configurar el transporte HTTPS aumenta la seguridad al asegurar la validez del servidor y cifrar tanto la autenticación como el tráfico de transporte. Al emitir un certificado, utiliza un certificado de confianza de una autoridad de certificación, cuando sea posible, en lugar de un certificado autofirmado.
Anfitriones de Confianza: Validando un Servidor
Cómo Funciona la Autenticación PSRemoting sobre WinRM
Como se mencionó anteriormente, uno de los primeros pasos por los que pasa PSRemoting es la autenticación. La autenticación es una de las partes más complicadas pero esenciales de PSRemoting.
Cuando PSRemoting se introdujo por primera vez, solo tenía un mecanismo de autenticación, la Gestión Remota de Windows (WinRM) pero hoy en día, también puedes autenticarte usando SSH, como verás más adelante.
WinRM admite dos tipos distintos de autenticación; un nombre de usuario y contraseña o un certificado con varios tipos de autenticación para una combinación de nombre de usuario/contraseña.
Autenticación Básica
Comenzando por el tipo de autenticación más fácil pero menos seguro, la autenticación básica. Este tipo de autenticación es un estándar incorporado en el protocolo HTTP. La autenticación básica envía una copia codificada en base64 del nombre de usuario y la contraseña en el encabezado HTTP desde el cliente hasta el receptor.
Debido a que la autenticación básica solo codifica el nombre de usuario y la contraseña y no los encripta, es trivial interceptar las credenciales a través de la red.
No utilice la autenticación básica a menos que sea absolutamente necesario. ¡Existen muchos otros métodos más seguros con los que WinRM puede autenticar!
Autenticación Kerberos
¿Tanto el cliente como el servidor están en un entorno de Active Directory? Si es así, ya estás utilizando la autenticación Kerberos en muchos de tus servicios de red.
Cuando el cliente de WinRM intenta conectarse a un receptor de WinRM a través de Kerberos:
- El servidor primero intenta recuperar una clave de sesión o un ticket de concesión de tickets para el cliente desde un controlador de dominio.
- El controlador de dominio busca el cliente y el servidor y, si ambos son válidos y confiables, emite el token.
- Luego, el servidor valida la conexión del cliente utilizando el token confiable en lugar del nombre de usuario y la contraseña.
Durante la autenticación de Kerberos, el controlador de dominio valida tanto al cliente como al servidor durante los pasos de recuperación del ticket, evitando que alguien malintencionado se haga pasar por el servidor.
Kerberos es un método de autenticación maduro y seguro, y es el tipo de autenticación predeterminado cuando un cliente y un servidor son miembros de un dominio de Active Directory. Sin embargo, requiere que ambos el cliente y el servidor estén unidos al mismo bosque de Active Directory o que haya una confianza establecida entre bosques.
Autenticación de Negociación
WinRm también puede intentar usar Kerberos y, si no está disponible, intentará utilizar un protocolo de autenticación llamado NT Lan Manager (NTLM).
Cuando se utiliza NTLM:
- El servidor envía al cliente una cadena.
- El cliente luego cifra la cadena con un hash de la contraseña del usuario.
- La cadena cifrada se envía luego de vuelta al servidor que envía el nombre de usuario, la cadena original y la cadena cifrada a un controlador de dominio.
- El controlador de dominio busca luego el hash de la contraseña para ese usuario y repite el mismo proceso de cifrado en la cadena para asegurarse de que coincida.
NTLM es bueno para validar al cliente, pero a diferencia de Kerberos, no valida al servidor. Esto abre la puerta a múltiples ataques donde el servidor podría ser suplantado por un atacante.
Puedes mejorar la seguridad de NTLM al validar también al servidor con un certificado de autenticación del servidor y asignarlo a un escuchador HTTPS de WinRM. En esta configuración, el cliente se autentica con NTLM contra el controlador de dominio, y el servidor se autentica con un certificado de confianza. Aunque esta configuración proporciona autenticación tanto para el cliente como para el servidor, el protocolo NLTM utiliza un cifrado más antiguo con un tamaño de clave desactualizado.
Por estas razones, NLTM solo es utilizable si agregas el servidor a la lista de hosts de confianza o utilizas un escuchador HTTPS.
Autenticación Digest
Uno de los métodos de autenticación menos comunes de usar en WinRM es la autenticación Digest. NTLM y Digest son métodos de autenticación similares. Al igual que NTLM, Digest genera una cadena única que se cifra con el hash de la contraseña del usuario. La contraseña no necesita ser enviada al servidor.
Digest utiliza el algoritmo de hash MD5 para cifrar la contraseña. Debido a esta elección de algoritmo, Digest generalmente se considera obsoleto y no debería usarse. MD5 tiene varias vulnerabilidades conocidas que lo hacen inadecuado para su uso criptográfico.
Proveedor de Soporte de Seguridad de Credenciales (CredSSP)
Aunque podríamos entrar en los pormenores de CredSSP, no es necesario. ¿Por qué? Porque cuando se trata de PSRemoting y WinRM, CredSSP se implementa típicamente por una razón, el “problema de segundo salto” que aprenderás a continuación.
Cuando está configurada para la autenticación de CredSSP, tanto el cliente como el servidor WinRM utilizan la autenticación de Negociación para autenticar tanto al usuario como al cliente. Pero una vez completado, la contraseña del usuario se envía al servidor.
Debido a que la contraseña se envía después de que se ha completado el proceso de autenticación, ahora está cifrada. CredSSP también cifra la contraseña con las claves de sesión TLS para que la cadena cifrada sea única entre sesiones.
CredSSP es útil porque después de la autenticación, el servidor puede conectarse a cualquier otra cosa en tu nombre. Sin embargo, cuando esto sucede, estás confiando completamente en el servidor al que te conectaste con la contraseña del usuario.
Autenticación basada en certificados
Quizás el método más seguro de autenticación para usar con PSRemoting es la autenticación basada en certificados. En este método de autenticación, se produce un intercambio de claves con una clave privada y pública en el cliente y un servidor que valida el certificado.
WinRM autentica al usuario mapeando un usuario en el servidor dentro de WinRM. Lo único que se pasa durante el proceso de autenticación es la clave pública, por lo que es una forma muy segura de autenticar
Aunque es la opción más segura, la autenticación basada en certificados no es muy común. ¿Por qué? Simplemente debido al trabajo necesario para configurarlo. Debes:
- Crear una autoridad de certificación
- Crear un certificado de autenticación de usuario
- Compartir la clave pública
- Usar una cuenta de usuario local con permisos adecuados (probablemente en el grupo de Administradores)
- Configurar un listener HTTPS
- …y otros pasos.
No puedes usar un usuario de dominio para autenticar con certificados incluso si el cliente y el servidor son parte de Active Directory.
Configuraciones predeterminadas de autenticación en el sistema operativo Windows
Ahora que has visto que hay muchas opciones de autenticación disponibles, ¿cómo sabes cuáles están disponibles por defecto? A continuación, verás una tabla con dos columnas que indican si el cliente WinRM, por defecto, está habilitado y si ese tipo de autenticación en particular está habilitado por defecto.
Todos los tipos de autenticación mencionados son configurables, pero al usar la tabla a continuación, tendrás una buena idea de lo que necesitarás configurar tú mismo.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
El Problema del Segundo Salto o Doble Salto
Uno de los mayores problemas con PSRemoting es conocido como el “problema del segundo salto” o “doble salto”. Esta situación ocurre cuando te conectas a un sistema remoto a través de PSRemoting y luego necesitas conectarte a otro equipo remoto.
Esta situación es problemática porque cuando el cliente WinRm se autentica en el primer equipo remoto, el servidor solo valida la identidad del cliente original sin enviar la contraseña al servidor. Cuando intentas conectarte al segundo equipo desde el servidor de la primera conexión, el servidor final no tiene forma de validar la identidad del usuario.
Puedes resolver el problema del doble salto de varias formas, ya sea mediante el uso de CredSSP o la Delegación de Kerberos.
Usando CredSSP
La forma más común de evitar el problema del doble salto es mediante el uso de CredSSP. La autenticación de CredSSP resuelve esta situación almacenando una credencial de usuario en el primer servidor remoto, la cual el servidor convertido en cliente puede luego pasar al segundo servidor remoto.
Hay un pequeño detalle al usar CredSSP. La credencial de usuario almacenada en el primer servidor remoto puede guardarse en texto plano, lo que introduce una preocupación de seguridad obvia. En sistemas operativos más nuevos, se utiliza un hash de la contraseña y el Ticket Granting Ticket (TGT) de Kerberos. Estos pueden usarse juntos para autenticarse como el usuario en cualquier parte de la red, igual que una contraseña en texto plano, pero reduce un poco el riesgo.
Con Negociar, el cliente y el servidor intercambian información para validar quiénes dicen ser, pero la contraseña del usuario nunca es accesible. Debido a esta característica de seguridad, no hay forma de que el primer servidor pueda autenticarte cuando te conectas al segundo servidor.
Usando Delegación de Kerberos
Kerberos, como se mencionó anteriormente, es una forma común de configurar PSRemoting. Al ser parte del omnipresente Active Directory y configurado por defecto, es extremadamente común. Aunque por sí solo, Kerberos es una forma adecuada de autenticar WinRM, no soluciona el problema de doble salto.
Para solucionar el escenario de doble salto, puedes utilizar un segundo tipo de autenticación conocido como Delegación de Kerberos. Aunque hay muchas variedades de Delegación de Kerberos, la única variedad capaz (y lo suficientemente segura) como para ser una alternativa a CredSSP se llama Kerberos Restringido Delegación, más específicamente Delegación de Kerberos restringida basada en recursos.
La Delegación de Kerberos restringida basada en recursos es una forma de delegar tokens de autenticación de Kerberos basados en recursos del dominio, como computadoras, en este caso, que está restringida a una lista específica de objetos de Kerberos (Active Directory).
Para configurar esta delegación Kerberos, es necesario editar el objeto ADComputer del tercer equipo en la cadena. Por ejemplo, si vas a conectarte de forma remota desde ClienteA a ServidorB y luego a ServidorC, debes editar el objeto ADComputer para ServidorC. Sin embargo, también necesitas saber cuál será el ServidorB. Para este ejemplo, ejecuta el siguiente comando en PowerShell:
“`powershell
El uso de la delegación Kerberos basada en recursos funciona para conexiones remotas como… o…, pero no funcionará con PSRemoting. No podrás conectar con un tercer equipo cuando estés conectado a una computadora a través de WinRM usando PSRemoting.
Configurar la Delegación Condicional Kerberos basada en recursos es un comando de una sola línea en PowerShell utilizando el cmdlet Set-ADComputer. Si, por ejemplo, estás conectado a ServidorB desde ClienteA a través de PSRemoting y deseas conectarte a ServidorC con…, puedes hacerlo ejecutando el siguiente comando en PowerShell.
WinRM almacena en caché las conexiones fallidas durante 15 minutos. Debido a esta característica, es posible que no puedas conectarte al tercer equipo incluso después de configurar la Delegación Condicional Kerberos basada en recursos. Para remediarlo, espera o ejecuta el comando
klist purge -LI 0x3e7en el tercer equipo para purgar los tokens Kerberos fallidos.
Cómo funciona la autenticación de PSRemoting sobre SSH.
Aunque la autenticación de WinRM es el método más común de autenticación para PSRemoting, a partir de PowerShell v6, tienes otra opción; SSH. Usar SSH como método de autenticación te permite utilizar PSRemoting con Linux.
SSH, a diferencia de WinRM, requiere alguna configuración adicional tanto en el cliente como en el servidor, como configurar un cliente SSH en el cliente de Windows y …
Usar SSH para manejar la autenticación significa que estás limitado a los tipos de autenticación que SSH soporta. Esto reduce la lista a los dos principales: basada en contraseña y basada en clave pública.
Existen otros tipos de autenticación soportados por SSH, pero generalmente se consideran menos seguros que las opciones basadas en contraseña y clave pública, así que nos centraremos en estas dos.
Autenticación por Contraseña
La forma más sencilla de configurar la autenticación SSH con PSRemoting es mediante la autenticación basada en contraseña. La autenticación basada en contraseña te permite proporcionar una contraseña para validarte.
En el proceso de autenticación SSH, la contraseña se intercambia después de establecer la conexión SSH y la contraseña se encripta durante la transmisión. A diferencia de algunos métodos de autenticación utilizados por WinRM, como Kerberos, este método de autenticación sí envía la contraseña completa al servidor.
Podrías comparar la autenticación de contraseña SSH con el método de autenticación básica de WinRM utilizando un listener HTTPS. La contraseña en sí misma no está protegida de ninguna manera significativa, pero toda la conexión, incluida la contraseña, está encriptada y el servidor se valida en función de un certificado.
Autenticación basada en certificados (Certificate-Based Authentication)
Aunque la autenticación basada en contraseña es fácil de configurar y sencilla de usar, presenta dos problemas.
- En primer lugar, no hay forma de autenticar de manera segura en un formato sin supervisión.
- La autenticación por contraseña aún envía una contraseña a través de la red. Si bien la contraseña se encripta dentro de la conexión SSH, el servidor recibe la contraseña completa. Si el servidor se ve comprometido de alguna manera, podría convertirse en un problema de seguridad.
Por otro lado, la autenticación basada en certificados no envía datos sensibles a través de la red, como la contraseña. En su lugar, el servidor tiene una copia de una clave pública, el cliente tiene una copia de la clave privada y la negociación ocurre en el servidor.
A rough workflow goes as follows:
- Cuando el cliente intenta autenticarse, envía el ID o huella digital de la clave pública al servidor.
- Si el servidor tiene la clave pública en la lista de autorizadas, responde con una cadena encriptada con la clave pública.
- Luego, el cliente desencripta la cadena con la clave privada.
- La clave privada se hashea con un ID de sesión.
- El ID de sesión se envía de vuelta al servidor, que luego lo compara con el hash generado usando la cadena original y el ID de sesión.
- Si el hash del ID de sesión del cliente coincide con el ID de sesión en el servidor, el cliente se autentica y se le permite conectar.
Todo lo cifrado con la clave pública solo puede descifrarse con la clave privada asociada. Todo lo cifrado con la clave privada solo puede descifrarse con la clave pública. También se incluye el ID de sesión para proporcionar lo que se llama Perfect Forward Secrecy (PFS).
PFS proporciona seguridad si la clave privada se ve comprometida, el atacante no podrá descifrar todos los mensajes que se han enviado. Un ID de sesión único significa que el secreto compartido utilizado para cifrar la comunicación es diferente para cada sesión.
La autenticación basada en certificados con SSH, como WinRm, requiere esfuerzo adicional para configurar, como generar la clave privada/pública y autorizar la clave pública en el servidor remoto.
Se requieren derechos de usuario para conectar.
Por defecto, dos grupos locales de usuarios pueden conectarse a un servidor de forma remota utilizando PSRemoting; Administradores y Usuarios de Administración Remota.
Mientras puedes agregar cuentas de usuario al grupo de Administradores local en un servidor remoto, siempre debes proporcionar la menor cantidad de acceso posible. Si un usuario simplemente necesita conectarse con PSRemoting a una computadora remota, puede agregar la cuenta de usuario al grupo Usuarios de Administración Remota; no a Administradores.
Para controlar aún más el acceso a PSRemoting, también puedes utilizar una característica llamada Administración Justa Suficiente (JEA). JEA permite que los usuarios que no son administradores solo ejecuten comandos específicos como administradores en el modo de lenguaje restringido de PowerShell.
Diferencia entre Remoting “Implícito” y “Explícito”
Si has utilizado PSRemoting antes, probablemente estés familiarizado con comandos como Invoke-Command, New-PSSession, Enter-PSSession, etc. Cuando ejecutas estos comandos, es evidente que te estás conectando de alguna manera a una computadora remota. Estás utilizando PSRemoting de manera explícita.
Cuando ejecutas comandos específicos de PSRemoting, estás ejecutando esos comandos de manera explícita, pero ¿sabías que hay otra forma? En lugar de invocar directamente Invoke-Command y otros cmdlets, puedes aprovechar PSRemoting mediante el uso de implícito PSRemoting.
El PSRemoting implícito puede parecer que estás ejecutando los comandos localmente dentro de tu sesión de PowerShell, pero en realidad se están ejecutando en una máquina remota. Un buen ejemplo de esto es usar un módulo que no está instalado en tu sistema. En lugar de instalarlo localmente, puedes exportar los comandos desde una PSSession, lo que te permitirá ejecutarlos como si estuvieran instalados localmente.
En la captura de pantalla a continuación puedes ver que no tengo el comando Test-PendingReboot. Luego me conecté a una máquina remota y exporté ese comando.
A continuación, si se importa ese módulo, puedo ejecutar el comando Test-PendingReboot. Esto se muestra a continuación, pero notarás que muestra que el nombre de la computadora en la salida no es el nombre del dispositivo desde el que se está ejecutando PowerShell, sino el dispositivo desde el que se importó el comando.
