Envío de comandos a otra aplicación de consola de PowerShell. Técnicas para trabajar con sistemas remotos a través de PowerShell. WinRM: administración remota de Windows

A menudo trabajo con comandos en sistemas remotos a través de PowerShell, tanto durante las pruebas de penetración como en las tareas diarias. Los comandos remotos se inician a través del protocolo WinRM (Windows Remote Management), que, hasta donde yo sé, es compatible con Windows Vista SP 1, Windows 7, Windows Server 2008 y Windows Server 2012.

Introducción

Ajustes iniciales

Antes de que pueda comenzar a trabajar con el sistema remoto, debe completar la configuración.

1. Inicie la consola de PowerShell como administrador y ejecute el siguiente comando:

Habilitar-PSRemoting -force

El comando anterior permite ejecutar comandos en sistemas remotos. Si tiene algún problema, utilice los siguientes comandos:

2. Asegúrese de que el servicio WinRM se inicie automáticamente.

# Establecer el modo deseado

Set-Service WinRM -StartMode Automático

# Compruebe que el servicio se esté ejecutando

Get-WmiObject -Class win32_service | Where-Object ($ _. Nombre -como "WinRM")

3. Establezca el estado de todos los hosts en "válido" (puede hacerlo más tarde).

# Confiamos en todos los anfitriones

Set-Item WSMan: localhost \ client \ trusthosts -value *

# Verifique la configuración de hosts confiables

Obtener elemento WSMan: \ localhost \ Client \ TrustedHosts

Ejemplos de trabajo con sistemas remotos

Ejecutando un solo comando en un sistema remoto

El comando "Invoke-Command" se utiliza para ejecutar comandos en sistemas remotos. Puede trabajar como usuario actual o utilizar una cuenta de terceros si está trabajando en un sistema que no forma parte de un dominio:

Invoke-Command –ComputerName MyServer1 -ScriptBlock (Nombre de host)
Invoke-Command –ComputerName MyServer1 -Credentials demo \ serveradmin -ScriptBlock (nombre de host)

Si se instala un módulo para trabajar con Active Directory, es posible ejecutar comandos en varios sistemas mediante una canalización:

Get-ADComputer -Filter * -properties name | select @ (Nombre = "nombre de equipo"; Expresión = ($ _. "nombre")) |
Invoke-Command -ScriptBlock (nombre de host)

A veces, en un sistema remoto, es necesario ejecutar un script almacenado localmente:

Invoke-Command -ComputerName MyServer1 -FilePath C: \ pentest \ Invoke-Mimikatz.ps1
Invoke-Command -ComputerName MyServer1 -FilePath C: \ pentest \ Invoke-Mimikatz.ps1 -Credentials demo \ serveradmin

Si genera comandos o funciones dinámicamente, que luego se pasan al sistema remoto, puede usar un montón de comandos invoke-expression e invoke-command:

$ MyCommand = "nombre de host"
$ MyFunction = "función malvada (write-host`" Obteniendo maldad ... `"; iex -command $ MyCommand); maldad "
invocar-comando -ComputerName MyServer1 -Credentials demo \ serveradmin -ScriptBlock
(Invocar-Expresión -Comando "$ args") -ArgumentList $ MyFunction

Organización de una consola interactiva en un sistema remoto

Puede configurar una consola interactiva de PowerShell en un sistema remoto usando el comando "Enter-PsSession" (un poco como SSH). El comando "Enter-PsSession" también se ejecuta como usuario actual o usando una cuenta alternativa:

Enter-PsSession –ComputerName server1.domain.com
Enter-PsSession –ComputerName server1.domain.com –Credentials domain \ serveradmin

La sesión se cierra con el comando "Exit-PsSession":

Creando sesiones en segundo plano

Otra característica útil le permite crear sesiones en segundo plano (el comando "New-PsSession"). Las sesiones en segundo plano pueden resultar útiles cuando se ejecutan varios comandos en varios sistemas. Al igual que los comandos anteriores, el comando "New-PsSession" se ejecuta en nombre del usuario actual o con una cuenta alternativa:

New-PSSession -ComputerName server1.domain.com
New-PSSession –ComputerName server1.domain.com –Credentials domain \ serveradmin

Si el módulo para trabajar con ActiveDirectory está instalado, es posible crear simultáneamente sesiones en segundo plano para múltiples sistemas (este truco se puede realizar diferentes caminos). A continuación, se muestra un ejemplo de cómo crear sesiones en segundo plano para todos los sistemas de un dominio. En el ejemplo, las sesiones se crean en un sistema que no es de dominio utilizando una cuenta de dominio alternativa.

New-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "
"-Servidor a.b.c.d -credencial dominio \ usuario
cd RemoteADS:
Get-ADComputer -Filter * -Properties name | seleccione @ (Nombre = "NombreDeEquipo"; Expresión = ($ _. "nombre"))
| New-PSSession

Listado de sesiones en segundo plano

Una vez que se han creado varias sesiones en segundo plano, puede ver la lista utilizando el comando "Get-PsSession".

Interactuar con sesiones en segundo plano

Al principio, tuve una sensación similar a cómo trabajaba con las sesiones en MetaSploit. Sin embargo, las sesiones en segundo plano en PowerShell son un poco más estables. A continuación, se muestra un ejemplo de interacción utilizando un ID de sesión:

Enter-PsSession –id 3

Para salir de la sesión, use el comando "Exit-PsSession". La sesión volverá al fondo.

Ejecución de comandos a través de sesiones en segundo plano

Si desea ejecutar el comando en todas las sesiones activas, utilice varios comandos "Invoke-Command" y "Get-PsSession".

Invoke-Command -Session (Get-PSSession) -ScriptBlock (Nombre de host)

Eliminar sesiones en segundo plano

Para eliminar todas las sesiones activas, utilice el comando "Disconnect-PsSession"

Get-PSSession | Desconectar-PSSession

Conclusión

Los comandos remotos en PowerShell abren enormes oportunidades tanto para los administradores como para los probadores de penetración. Independientemente de la situación, cómo trabajará con los sistemas remotos, todo se reduce a lo siguiente:

Utilice Invoke-Command para ejecutar un solo comando en un sistema remoto.
Utilice Enter-PSSession para interactuar con un solo sistema.
Si desea ejecutar varios comandos en varios sistemas, utilice sesiones en segundo plano.

Espero que este artículo le haya resultado útil.

04.03.2011 Bill Stewart

V Versiones de Windows PowerShell 2.0 implementa un mecanismo alternativo para conectarse a computadoras remotas llamado comunicación remota. Este mecanismo utiliza las facilidades del servicio control remoto Windows (administración remota de Windows, WinRM). Proporciona conectividad a una computadora remota, así como el lanzamiento de comandos ejecutados en esa computadora remota.

El desarrollo de PowerShell 1.0 supuso un gran avance en las herramientas de gestión y automatización de Windows XP y versiones posteriores de la plataforma del sistema operativo Windows. Basado en plataforma. NET Framework La tecnología PowerShell 1.0 incluye una estructura de comandos coherente (cmdlets), tiene potentes herramientas de formato de salida integradas y proporciona un aumento significativo en la disponibilidad de otras tecnologías, en particular Windows Management Instrumentation (WMI). Sin embargo, aunque algunos compuestos Comandos de PowerShell 1.0 y objetos. NET puede conectarse a equipos remotos, esta función se implementa de manera diferencial, según el caso específico. Los comandos que admiten conexiones remotas tienen el parámetro -ComputerName; además, utilizan llamadas a procedimiento remoto (RPC) o DCOM para establecer conexiones.

En muchas situaciones, RPC y DCOM hacen un buen trabajo de administración, pero a veces surgen problemas al realizar diagnósticos e identificar la causa raíz de los problemas. Por ejemplo, el comando Get-Service puede leer datos de servicio desde una computadora remota usando el parámetro -ComputerName, pero este comando no tiene un parámetro -Credential y, por lo tanto, debe iniciar sesión con una cuenta que tenga permiso para acceder al sistema remoto. para ejecutarlo.

Sin embargo, Windows PowerShell 2.0 presenta un mecanismo alternativo para conectarse a equipos remotos denominado comunicación remota. Este mecanismo utiliza las herramientas del servicio de administración remota de Windows (WinRM). Proporciona conectividad a una computadora remota, así como el lanzamiento de comandos que se ejecutan en esa computadora remota. Déjame explicarte esto con un ejemplo. Conectores de escritorio remoto se refiere a una interfaz gráfica de usuario de la misma manera que la comunicación remota es a la línea de comandos de PowerShell. Cuando ejecuta un comando compuesto usando la comunicación remota, el comando realmente se ejecuta en la máquina remota, pero puede ver los resultados en la máquina local.

Dónde obtener Windows PowerShell 2.0

PowerShell 2.0 y WinRM se incluyen con Windows 7 y Windows Server 2008 R2, por lo que si utiliza estos sistemas operativos, no es necesario que instale estos componentes. Si trabajas con Sistemas Windows Vista SP2, Windows XP SP3, Windows Server 2008 SP2 o Windows Server 2003 SP2, deberá descargar e instalar Paquete de Windows Management Framework Core (support.microsoft.com/kb/968930).

Habilitación de la funcionalidad de comunicación remota

Para que la computadora pueda conectarse a sistemas remotos que tienen PowerShell instalado, se deben cumplir las siguientes condiciones.

El servicio WinRM debe estar activado.
Se debe instalar un oyente de WinRM que acepte conexiones desde una o más direcciones IP.
Cortafuegos Windows debe estar configurado para poder establecer conexiones a través de WinRM.
La sesión de PowerShell debe estar habilitada y configurada correctamente.

Si la computadora no acepta conexiones de PowerShells instaladas en computadoras remotas, ejecute condiciones especificadas no es necesario.

Para ayudar a los usuarios a comenzar lo antes posible, los desarrolladores de Microsoft PowerShell crearon el comando Enable-PSRemoting para configurar automáticamente estos componentes. Esta configuración no debe realizarse en la máquina con la que interactuará de forma remota, sino en la computadora a la que accederá de forma remota. Puede ejecutar el comando Enable-PSRemoting solo si está ejecutando PowerShell como administrador. Si esta trabajando con Máquinas Windows Vista, Server 2008 y versiones posteriores, haga clic con el botón derecho en el icono de PowerShell y seleccione Ejecutar como administrador en el menú desplegable. Si ejecuta el comando Enable-PSRemoting con el parámetro -Force, el sistema no le pedirá permiso para completar cada paso de configuración cuando se ejecute. Para obtener más información sobre el comando compuesto Enable-PSRemoting, ejecute el comando

Get-Help Enable-PSRemoting

Ejecutando un comando en una computadora remota

La forma más sencilla de conectarse a PowerShell en una computadora remota es con el comando Enter-PSSession. De forma predeterminada, este comando se ejecuta con el parámetro -ComputerName, por lo que no es necesario que especifique este parámetro al escribirlo desde el teclado. Por ejemplo, para establecer una conexión con una computadora remota llamada rigel, ingrese desde el teclado

PS C: \> Enter-PSSession rigel

Tenga en cuenta que, para completar, incluyo una invitación en el texto. No es necesario que ingrese el indicador como parte del comando.

Después de ingresar a una sesión remota, la sintaxis del indicador de PowerShell cambia. Ahora incluirá el nombre de la computadora remota entre corchetes; esto significará que ha establecido una conexión con la computadora remota. En este caso, la invitación se verá así:

: PS C: \>

Después de establecer conección remota Todos los comandos que ingrese en la línea de comandos se ejecutarán en la máquina remota. Entonces, si ingresa el comando

: PS C: \> Get-ChildItem C: \

el comando Get-ChildItem se ejecutará en la máquina remota. Su salida contendrá los nombres de los archivos y carpetas almacenados en la unidad C de la computadora remota. Para finalizar la sesión remota, use el comando Exit-PSSession

: PS C: \> Salir-PSSession

Ejecución de un Scriptblock en una computadora remota

La comunicación remota de PowerShell le permite ejecutar un bloque de script o scriptblock (es decir, un bloque de código de PowerShell entre llaves) en una computadora remota. Para hacer esto, use el Invoke-Command con el parámetro -ComputerName. Por ejemplo, en el comando que se muestra en la Figura 1, utilicé Invoke-Command para ejecutar Get-ChildItem en una computadora remota. Mientras revisa la Figura 1, observe que no utilicé el comando Enter-PSSession para establecer una conexión con la computadora remota antes de ejecutar el bloque de secuencia de comandos. Enter-PSSession e Invoke-Command son dos métodos de comunicación remota diferentes.

El primer parámetro del Invoke-Command es el parámetro -ScriptBlock; apunta al código que está a punto de ejecutar. En la Figura 1, omití el nombre del parámetro -ScriptBlock porque es opcional. El parámetro -ComputerName contiene el nombre del equipo remoto. Como puede ver en la salida del comando Get-ChildItem, PowerShell incluso enumera el nombre de la computadora remota en la columna PSComputerName de la salida para comodidad del operador.

Ejecutar un bloque de script en varias computadoras remotas

El bloque de script también se puede ejecutar en varios equipos remotos. Esto se denomina configuración de uno a varios o implementación continua. En la Figura 1, el parámetro -ComputerName para Invoke-Command contiene un solo nombre, pero también puede incluir varios nombres de computadora. Entonces, el comando

PS C: \> Invoke-Command (Get-ChildItem env: co *) -Computer titan, rigel

permite que el comando Get-ChildItem se ejecute en dos equipos remotos. En el texto del artículo, este comando se divide en varias líneas, pero en Consola de PowerShell debe ingresarse en una línea. Lo mismo ocurre con otros comandos que se dividen en varias líneas. Como en la Figura 1, la columna PSComputerName en la salida contendrá los nombres de las computadoras.

Ejecutar un bloque de script en segundo plano

PowerShell 2.0 habilita trabajos en segundo plano, lo que significa que el operador puede ejecutar un comando en segundo plano. Esta función es útil cuando se ejecutan comandos que tardan mucho en completarse.

Puede utilizar el comando Start-Job para iniciar un trabajo en segundo plano en la computadora local. Pero debo decir que este comando no tiene un parámetro -ComputerName, lo que significa que no se puede usar para ejecutar un trabajo en segundo plano en una máquina remota. En su lugar, deberá ejecutar Invoke-Command con el parámetro -AsJob. Por ejemplo, el comando top en la Figura 2 inicia el bloque de script como un trabajo en segundo plano en la computadora remota Titan. Después de ingresar este comando, el mensaje apareció inmediatamente en la pantalla: PowerShell envió un bloque de script para su ejecución a la computadora remota y luego me devolvió el control. La advertencia indica que el comando ejecutado no cabía en la ventana de la consola y, por lo tanto, no se incluyó en la salida. Si tuviera una ventana de consola más amplia, el formateador de PowerShell incluiría el comando en la salida. Las columnas Id y Nombre indican el trabajo (su identificador y nombre descriptivo, respectivamente), y la columna Estado indica si el trabajo está en progreso, en pausa o completado. La columna HasMoreData contiene información que indica que se han recuperado todos los datos de un trabajo determinado o que el trabajo contiene más información que debe recuperarse.

Puede ejecutar el comando Get-Job para determinar si se ha completado un trabajo en segundo plano, como muestra el segundo comando en la Figura 2. Si no usa ningún parámetro, Get-Job verifica el estado de todos los trabajos que se están ejecutando en la sesión actual. . Si tiene varios trabajos ejecutándose al mismo tiempo, puede usar opciones como -Id o -Name para especificar qué trabajo desea verificar. Cuando se complete el trabajo en segundo plano, se completará la columna Estado de la salida.

Puede utilizar el comando Recibir trabajo para leer los resultados de un trabajo en segundo plano. Este comando, al igual que el comando Get-Job, devuelve el resultado de todos los trabajos iniciados en la sesión actual, a menos que haya utilizado un parámetro para indicar en qué trabajo está interesado. Por ejemplo, el último comando en la Figura 2 incluye el parámetro -Id, que indica que desea la salida para el ID de trabajo 9. Omití el nombre del parámetro -Id porque es opcional. La Figura 3 muestra las últimas líneas de salida relacionadas con la ejecución del trabajo en segundo plano remoto en cuestión.

Crear sesiones de PowerShell

Los ejemplos anteriores muestran cómo acceder al indicador de PowerShell en una máquina remota y cómo ejecutar comandos en computadoras remotas. Pero todavía no he mencionado que la comunicación remota siempre se realiza en el contexto de la sesión. Una sesión es, digamos, el hogar de PowerShell. Cuando abre una ventana de la consola de PowerShell o la ventana del entorno de scripting integrado (ISE) de PowerShell, crea una sesión. Sin la comunicación remota, todas las sesiones se ejecutan en la computadora local y son independientes entre sí. Todos los ejemplos de comunicación remota anteriores crean sesiones temporales que se terminan automáticamente cuando finaliza la comunicación remota. Además, es posible crear instancias de sesiones remotas y reutilizarlas. Este enfoque es mucho más efectivo cuando necesita acceder a computadoras remotas más de una vez.

Para crear nuevas sesiones, use el comando New-PSSession con el parámetro -ComputerName. El nombre de este parámetro se puede omitir en los comandos. Entonces, el comando

C: \> $ sesiones = New-PSSession phineas, ferb, perry

crea tres sesiones en tres computadoras llamadas phineas, ferb y perry. Puede ver estas sesiones creando la variable $ sesiones. Para hacer esto, ingrese el nombre en la línea de comando

$ sesiones

y presione enter. El parámetro -Session de Invoke-Command admite objetos de sesión creados con el comando New-PSSession, por lo que puede usar un comando como el siguiente:

C: \> Invoke-Command (Get-ChildItem) -session $ sesiones

Este comando ejecuta el comando Get-ChildItem en las máquinas phineas, ferb y perry, pero no se desconecta. Puede agregar el parámetro -AsJob y ejecutar el comando en segundo plano:

C: \> Invoke-Command (Get-ChildItem) -session $ sesiones -asjob

Un nuevo enfoque de trabajo

La comunicación remota de PowerShell es un nuevo y poderoso mecanismo para ejecutar comandos en computadoras remotas. Espero que este artículo lo motive a explorar nuevas posibilidades. Puede encontrar información más detallada sobre la comunicación remota, incluidos los problemas de diagnóstico, en los temas de referencia de PowerShell about_Remote en technet.microsoft.com/en-us/library/dd347616.aspx.

Bill Stewart ( [correo electrónico protegido]) - Administrador de sistemas y redes para la morgue francesa, Nuevo México

Administración remota con PowerShell

Existen bastantes métodos para trabajar con equipos remotos. Hay Gestión de Windows Instrumentación (WMI), ampliamente utilizada en VBScript. Existen varias utilidades que permiten el control remoto, como las de Sysinternals. Incluso muchos cmdlets de PowerShell tienen un parámetro ComputerName para ejecutarse en equipos remotos.

En general, existen muchos métodos, pero cada uno de ellos tiene sus inconvenientes. En primer lugar, la sintaxis es diferente, con lo que es fácil confundirse. En segundo lugar, algunos comandos se comportan de manera diferente dependiendo de si se ejecutan de forma local o remota. Finalmente, la comunicación puede requerir la apertura de puertos adicionales en el firewall, lo cual no es bueno desde el punto de vista de la seguridad.

Comunicación remota de PowerShell resuelve la mayoría de los problemas descritos. Se basa en la implementación de Microsoft del protocolo Web Services for Management (WS-Management) y utiliza un servicio (WinRM) para la comunicación. La comunicación entre computadoras se realiza a través de HTTP (predeterminado) o HTTPS. Todo el tráfico entre dos computadoras está encriptado a nivel de protocolo (excepto cuando se usa SSL). Se admiten varios métodos de autenticación, incluidos NTLM y Kerberos.

A diferencia de las utilidades que usan diferentes interfaces de programación, PS Remoting funciona de la siguiente manera: los comandos ingresados en la computadora local se transmiten a la computadora remota y se ejecutan allí, luego el resultado se envía de regreso. Dado que todos los comandos se ejecutan localmente, no hay necesidad de preocuparse por la compatibilidad. Además, PS Remoting solo necesita una puerto abierto en el cortafuegos.

Hay varias formas de administrarlo mediante PowerShell Remoting.

Control uno a uno

La forma más sencilla de controlar de forma remota es abrir de forma interactiva sesión remota y realizar las acciones necesarias en él. Por ejemplo, abramos una sesión en la computadora SRV4 y reiniciemos el servicio de impresión en ella:

Enter-PSSession -ComputerName SRV4
Restart-Service -Name spooler

Veamos el estado del servicio y cerremos la sesión remota:

Get-Service -Name spooler
Salir-PSSession

El trabajo interactivo es adecuado para resolver tareas simples administración remota. Si necesita automatizar el proceso, es mejor usar el cmdlet Invoke-Command. Así es como puedes hacer la misma acción con él:

Invocar-Comando -ScriptBlock (Restart-Service spooler) -ComputerName SRV4

Este comando abrirá una sesión remota en SRV4, ejecutará el bloque de comando especificado en el parámetro -ScriptBlock y cerrará la sesión. Y para ejecutar el trabajo en segundo plano, opcionalmente puede especificar el parámetro -AsJob.

Tenga en cuenta que cuando se ejecuta en segundo plano, PowerShell no devuelve ningún resultado. Para obtenerlo, deberá usar el cmdlet Receive-Job.

Para ejecutar no un par de comandos, sino un script, Invoke-Command tiene un parámetro –FilePath, que se puede usar en lugar de –ScriptBlock para definir un archivo de script. Por ejemplo, creé un script que enumera los servicios detenidos y lo inicié en una máquina SRV4 remota:

Invoke-Command -FilePath. \ Script.ps1 -ComputerName SRV4

Gestión uno a muchos

Muy a menudo, es necesario ejecutar una tarea en paralelo en varios equipos. Esto se puede hacer con bastante facilidad usando el mismo Invoke-Command. Por ejemplo, los nombres de las computadoras se pueden enumerar simplemente, separados por comas:

Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName SRV4, SRV5

Colocar en variable:

$ servidores = @ (″ SRV1 ″, ″ SRV2 ″, ″ SRV3 ″)
Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName $ servidores

O tome del archivo:

Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName`
(Get-Content. \ Servers.txt)

Nota: Invoke-Command tiene un parámetro ThrottleLimit que limita cantidad maxima ordenadores que se pueden controlar al mismo tiempo. Por defecto, este parámetro es 32. Puede cambiarlo si es necesario, pero tenga en cuenta que aumentar este parámetro aumentará la carga en el procesador y la memoria de su computadora, por lo que esta operación debe realizarse con mucho cuidado.

Sesiones

Cada vez que ejecuta Invoke-Command, se crea una nueva sesión, que requiere tiempo y recursos para crearse. Para evitar esto, podemos abrir una sesión en la que ejecutar todos los comandos. Por ejemplo, abramos una sesión llamada SRV4 en la computadora SRV4 y colóquela en la variable $ session, y luego esta sesión realizará nuestra tarea (detenga el sufrido spooler):

$ session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock (Get-Service spooler | Stop-Service) `
-Sesión $ sesión

La sesión estará activa hasta que salgamos de la consola de PowerShell. También puede cerrar la sesión - Disconnect-PSSession o eliminar - Remove-PSSession.

Ahora, aquí hay algunas características interesantes introducidas en PowerShell 3.0. Si antes, cuando sale de la sesión o cierra la consola, la sesión se eliminó, entonces en PS 3.0, cuando cierra la sesión, pasa al estado desconectado... Podemos abrir una nueva sesión en la misma (o en cualquier otra) computadora y ejecutar el comando directamente en esta sesión desconectada. Como ejemplo, iniciamos el servicio de impresión en la computadora SRV4, que se detuvo la última vez:

Invoke-Command -ScriptBlock (Inicio de cola de servicio) `
-ComputerName SRV4 -Disconnected

Otra opción para usar sesiones desconectadas es iniciar tareas que requieren mucho tiempo. Por ejemplo, abramos una sesión llamada LongJob en SRV4 y lancemos un trabajo en segundo plano en ella, que mostrará una lista de servicios con un intervalo de 1 minuto:

$ session = New-PSSession -ComputerName SRV4 -Name LongJob
Invocar-Comando-Sesión $ sesión -ScriptBlock`
(Get-Service | foreach ($ _; sleep 60)) -AsJob

Veamos cómo se realiza la tarea y cerramos la sesión:

Recibir-Trabajo-Nombre Trabajo2
Disconnect-PSSession $ sesión

Vamos a otra computadora y abrimos la consola, nos conectamos a la sesión LongJob y usamos el cmdlet Receive-PSSession para obtener el resultado de la tarea:

Connect-PSSession -Name LongJob -ComputerName SRV4
Receive-PSSession -Name LongJob

U otra opción, sin conectarse explícitamente a la sesión usando Connect-PSSession:

$ session = Get-PSSession -Name LongJob -ComputerName SRV4
$ job = Receive-PSSession $ session -OutTarget Job
Recibir-trabajo $ trabajo

Nota: Para que el resultado permanezca en el sistema, Receive-Job debe usarse con el parámetro -Keep.

Control remoto implícito

Otro método de control remoto bastante poco convencional es la comunicación remota implícita. Al usarlo, puede ejecutar cmdlets localmente ubicados en la computadora remota sin crear una sesión remota.

Por ejemplo, tomemos una estación de trabajo normal sin herramientas de administración remota instaladas. Cree una sesión remota con el controlador de dominio SRV4 e importe el módulo a esta sesión Directorio Activo:

$ session = New-PSSession -ComputerName SRV4
Invoke-Command (Import-Module ActiveDirectory) -Session $ session

Luego exportamos los cmdlets de Active Directory desde la sesión remota y los colocamos en el módulo RemoteAD local:

Export-PSSession -Session $ session -CommandName * -AD * -OutputModule RemoteAD`
-PermitirClobber

Este comando creará un nuevo módulo de PowerShell en la carpeta WindowsPowerShell \ Modules \ RemoteAD. Solo se cargarán los cmdlets con nombres que coincidan con el patrón * -AD *. Sin embargo, los propios cmdlets no se copian en computadora local... El módulo local sirve como una especie de acceso directo y los comandos mismos se ejecutarán en el controlador de dominio remoto.

Después de crear el módulo, la sesión remota se puede cerrar, ya no es necesaria.

Importamos el nuevo módulo a la sesión actual (en PS 3.0, puede omitir este paso):

Módulo de importación RemoteAD

Ahora atención, no estamos abriendo una sesión remota con el controlador de dominio donde se encuentran los cmdlets. No es necesario que inicie explícitamente esta sesión, se puede hacer implícitamente intentando ejecutar cmdlets remotos:

New-ADUser -Name BillGates -Company Microsoft
Get-ADUser BillGates

Esto restaurará la conexión remota al controlador de dominio, después de lo cual el comando se enviará al controlador de dominio y se ejecutará allí. El resultado de la ejecución se serializará en XML y se transmitirá a través de la red a la computadora local, donde se deserializará en objetos con los que PowerShell puede trabajar.

La sesión remota permanecerá activa hasta que cierre la consola o desinstale el módulo RemoteAD.

El control remoto implícito le permite trabajar con cmdlets en una computadora remota de la misma manera que si estuvieran instalados en la máquina local. Al mismo tiempo, todos los cmdlets necesarios están siempre a mano, lo cual es bastante conveniente.

En conclusión, diré que en este momento PowerShell Remoting es la principal herramienta para la gestión remota de los sistemas operativos Windows. Por lo tanto, cualquier administrador de Windows debe conocer sus capacidades y poder utilizarlas.

Este artículo explica en detalle el tema de la comunicación remota con PowerShell 2.0. En primer lugar, debemos poner en marcha el servicio con el que se realizará la interacción remota.

Arrancamos el servicio WinRm
Para la comunicación remota, PowerShell 2.0 usa el servicio WinRM, que está preinstalado en Windows 7 y Windows 2008 R2 de forma predeterminada. Para más primeras versiones sistema operativo debe instalarse adicionalmente. El servicio especificado se instala en la máquina cuando instalar PowerShell 2.0. Para verificar que WinRM está presente, inicie la consola de PowerShell 2.0 y ejecute el comando en ella:
Obtener servicio WinRm
El resultado se verá así:

Nombre de estado DisplayName ------ ---- ----------- Detenido winrm Windows Remote Management (WS-Manag ...

Como puede ver, el servicio está presente, pero no iniciado. Para iniciar WinRm, debe ejecutar el comando desde la consola de PowerShell 2.0 con derechos de administrador:
Habilitar PSRemoting
A la solicitud para confirmar el inicio del servicio, presione el botón "Y". El servicio WinRM ahora está configurado para el tipo de inicio "Automático"; se ejecutará cada vez que se inicie la computadora. El comando Enable-PSRemoting no solo inicia el servicio y cambia su tipo de inicio, sino que también configura el firewall correctamente para que funcione correctamente. El servicio WinRm acepta solicitudes de cualquier dirección IP.

Solicitamos los nombres de todos los proveedores conectados:
Get-PSProvider
Como puede ver, ahora tenemos otro proveedor llamado WSMan.
Asignar nodos de confianza

En la consola de PowerShell 2.0, ejecute los comandos con derechos de administrador:

Set-Location –Path WSMan: Set-Location –Path localhost \ client Get-ChildItem

Nota
Tenga en cuenta que en el primer comando, el valor del parámetro –Path termina con dos puntos porque se trata de un proveedor.

En la computadora con la que desea trabajar de forma remota, debe especificar qué servidores pueden conectarse a esta máquina. Estos servidores se conocen como "sitios de confianza". Por lo tanto, si está en el servidor "MyServer", antes de poder trabajar de forma remota con la computadora "MyComputer", debe configurar los hosts de confianza (TrustedHosts). El siguiente método para asignar sitios de confianza se utiliza cuando el equipo no es miembro de un dominio de Active Directory. Si la computadora es miembro de un dominio de Active Directory, la configuración de TrustedHosts se puede configurar a través de la Política de grupo.

¡Importante!
El siguiente comando no funcionará si WSMan: \ localhost \ client no está instalado en el directorio actual (vea la invocación del comando que hicimos arriba).

Set-Item TrustedHosts *

Puede ejecutar el comando desde un directorio diferente, pero luego debe especificar la ruta completa a TrustedHosts:

Conjunto de elementos WSMan: \ localhost \ Client \ TrustedHosts *

En la solicitud de confirmación, presione la tecla "Y".

Para que PowerShell vea los cambios que hicimos en la configuración de TrustedHosts, debe reiniciar el servicio WSMan. Esto se hace con el siguiente comando:
Reiniciar-Servicio winrm

Se puede realizar una acción similar desde DOS. Ejecute el comando winrm -?. Verá ayuda general para el comando. Para ver el valor actual de TrustedHosts, ejecute el comando:

winrm obtiene winrm / config / client

y para establecer el valor, debe ejecutar:

winrm establece winrm / config / client / @ (TrustedHosts = "*")

En los comandos anteriores, para TrustedHosts, se especificó el símbolo "*" como valor, sin embargo, en lugar de él, puede especificar los nombres de servidores específicos. La administración de TrustedHosts es un caso clásico para usar los verbos Get y Set de PowerShell en conjunto: usa Get-Item y Set-Item.
Crear y finalizar una sesión remota de PowerShell 2.0
En los siguientes comandos, en lugar de "IpAddress", especifique la dirección IP deseada y, en lugar de "FQDN", especifique el nombre de dominio completo:

Enter-PSSession IpAddress

Enter-PSSession FQDN

Para finalizar una sesión de trabajo remoto, ejecute el comando:

El comando Enter-PSSession requiere un nombre de dominio completo. Por ejemplo, en el caso de MyServer.domain.local, simplemente especificar MyServer no funcionaría, pero usar la dirección IP siempre funciona bien en situaciones como esta. Método alternativo de PSSession:

New-PSSession -computername testMachine2 Get-PSSession

Puede finalizar esta sesión así:

Get-PSSession | remove-PSSession

Si desea probar el trabajo remoto, pero no tiene una segunda máquina, cree una "conexión remota" de su computadora para usted. Por ejemplo, si su máquina se llama "MyMachine", intente esto:

New-PSSession -computername MyMachine

Puede parecerle extraño y no lógico, pero de esta manera aún puede probar el trabajo remoto en PowerShell 2.0.

Trabajar en una sesión remota de PowerShell 2.0
Después de crear una conexión remota, puede organizar las canalizaciones de comandos ejecutándolas en la consola de PowerShell 2.0, pero al mismo tiempo se ejecutarán en la máquina remota, como si estuviera en su teclado y escribiendo comandos allí, no aquí. Por ejemplo, ejecute un comando como este y vea el resultado de su trabajo:

Set-Location c: \ | Get-childitem

Dado que el propósito principal de este tutorial es ayudarlo a crear una sesión de conexión remota de PowerShell 2.0 y mostrarle cómo cerrarla, tendrá que decidir por sí mismo qué operaciones desea realizar durante la conexión remota.

Nota
Si le parece que algún comando no funciona para una sesión de conexión remota, pruébelo primero en su máquina local.

Tan pronto como la conexión remota funcione para usted, inmediatamente le brinda la capacidad de usar PowerShell 2.0 para administrar computadoras conectadas a su red. Ahora puede ejecutar scripts en otras máquinas. En PowerShell 2.0, muchos cmdlets admiten el parámetro "-computerName", pero una conexión remota le permite usar los comandos de la familia PSSession, así como invocar Invoke-Command (es decir, puede hacer lo que quiera).

Solución de problemas de PowerShell 2.0 Remote

Un problema común es el ERROR "Acceso denegado".

Solución:
Ejecute PowerShell 2.0 como administrador. Pruebe en ambas máquinas (la que se está conectando y la que se está conectando) para establecer la configuración de "TrustedHosts" en * (asterisco). Solo recuerda que esta opción permite conexiones desde cualquier lugar.
Recuerde reiniciar el servicio WinRm; de lo contrario, los cambios que realizó en "TrustedHosts" no surtirán efecto. Para reiniciar el servicio, ejecute el comando en la consola de PowerShell 2.0: Restart-Service WinRm
Además, tenga cuidado de no confundir el nombre del proveedor de WSMan con el nombre del servicio WinRm.
Otro consejo extraño, pero a veces útil: intente volver a intentar la conexión remota. Curiosamente, puede que no funcione en el primer intento, pero podría funcionar en el segundo o tercer intento. Aquellos. debe volver a ejecutar el comando: Enter-PSSession -computerName myOtherMachineName

Cortafuegos, PowerShell 2.0 y el servidor rpc no está disponible
Los especialistas en seguridad levantarán la mano horrorizados ante tal propuesta, sin embargo, en caso de recibir el error anterior, sugiero que desactive el firewall en ambas computadoras. Si todo funciona bien después del apagado, debe verificar el uso de los puertos 135 y 445. Configure excepciones para estos puertos en los firewalls; esto permitirá que PowerShell 2.0 funcione de forma remota y, al mismo tiempo, el firewall protegerá la computadora de amenazas.

PD He leído que el comando Enable-PSRemoting debería hacerse cargo de los cambios automáticos en la configuración del firewall, pero en mi experiencia, este no es siempre el caso.
Para obtener información sobre cómo deshabilitar el firewall en Windowws 8 usando la Política de grupo, lea.

Dos tipos usados para el trabajo remoto en PowerShell 2.0
Es hora de anunciar que hay dos opciones para el trabajo remoto en PowerShell 2.0.
El primer método es una variación más sofisticada que usa cmdlets para crear una tubería persistente a la segunda máquina. Los nombres de dichos comandos contienen la palabra "PSSession" como sustantivo (recuerde que los nombres de los cmdlets se crean de acuerdo con la regla "Verbo-Sustantivo"). Puede obtener una lista de estos cmdlets con el siguiente comando:

Get-Command -noun PSSession

La segunda forma es también la forma más canónica de trabajo remoto de PowerShell 2.0. Este método simplemente expande los comandos locales agregando el parámetro "-computerName", que especifica la computadora remota en la que realizar la operación. Como resultado, dichos comandos se ejecutarán en otra máquina de la red:

Obtener proceso -computerName machine2

Lista de cmdlets que se pueden usar así de una manera sencilla(es decir, aquellos que tienen el parámetro "-computerName") se pueden obtener usando el siguiente comando:

Get-command | donde ($ _. parameters.keys -contiene "ComputerName")

Se puede obtener una lista completa de cmdlets que pueden funcionar de la segunda forma de la siguiente manera:

Get-command | donde ($ _. parameters.keys -contiene "ComputerName" -y ($ _. parameters.keys -notContains "Session"))

Resumen del trabajo remoto en PowerShell 2.0
El secreto para trabajar de forma remota con PowerShell 2.0 es comprender las cosas básicas:
Instale WinRm.
La comunicación remota debe habilitarse mediante el comando Enable-PSRemoting.
Debe configurar TrustedHosts (por ejemplo, establecerlo como un valor *).
Cuando utilice el comando Enter-PSSession, recuerde especificar el nombre de host completo o la dirección IP.

Una fuente de información en inglés presentada y ligeramente revisada por mí.

# Cree una nueva sesión para conectarse a la máquina remota $ s = New-PSSession -computername TestComputer

# Realizamos acciones arbitrarias en la máquina remota, por ejemplo, mire el contenido del directorio C:
Invocar-Comando-Sesión $ s -ScriptBlock (ls c: \)

# Crear directorio "% ProgramFiles% \ MyCompany \ MySoft" en la máquina remota
Invoke-Command -Session $ s -ScriptBlock (New-Item -Path "$ env: ProgramFiles \ MyCompany \ MySoft" -ItemType directorio)

# Sin embargo, es mucho más conveniente no ingresar comandos manualmente, sino ejecutar un script listo para usar en una máquina remota:
Invoke-Command -Session $ s -FilePath "\\ ServerDir \ Common Scripts \ MyScript.ps1"

# Finalizar la sesión
$ s | remove-PSSession

Tutorial

Hay un mínimo de teoría, principalmente una parte práctica. Describe cómo configurar WinRM, cómo cambiar el perfil de un adaptador de red, proporciona un script para agregarlo a TrustedHosts con filtrado, explica por qué se necesitan hosts confiables y lo cubre de manera superficial. conexiones remotas para que pueda sentarse y administrar inmediatamente las máquinas remotas.

La forma más sencilla de configurar el control remoto es Habilitar PSRemoting en powershell con derechos de administrador. En este caso, ocurrirá lo siguiente:

el servicio WinRM se iniciará (si se inicia, se reiniciará)
el servicio WinRM entrará en el estado - inicio automático al inicio
se creará un oyente de WinRM para HTTP tráfico en el puerto 5985 para todas las direcciones IP locales
Se creará una regla de firewall para el oyente de WinRM. Atención, este elemento terminará con un error si alguna de las tarjetas de red es del tipo de red "pública", porque abrir un puerto en una tarjeta de este tipo no es bueno. Si obtiene un error de este tipo al configurar, cambie el perfil de esta chica de la red usando el cmdlet Set-NetConnectionProfile y luego ejecute Enable-PSRemoting nuevamente. Si necesita una tarjeta de red con el perfil "Red pública", ejecute Enable-PSRemoting con el parámetro -SkipNetworkProfileCheck en este caso, las reglas de firewall se crearán solo a partir de red local.

Después de eso, debe permitir la conexión a la máquina remota desde la máquina desde la que se realizará el control. Esto se hace por razones de seguridad para reducir el riesgo de piratear la sesión de control remoto o el DNS sustituyéndose a sí mismo en lugar de la máquina remota y para evitar la ejecución de scripts en máquinas que no ha permitido a la fuerza.

Para comprobar dónde puede conectarse, utilice:
get-item wsman: \ localhost \ Client \ TrustedHosts
por permiso para conectarse a todos
set-item wsman: localhost \ client \ trusthosts -value *
Si abre el acceso a todos especificando *, entonces WinRM se conectará a TODAS las máquinas sin verificar. Recuerde que se está abriendo a posibles piratas informáticos de su red local. Es mejor especificar las direcciones de host donde necesita conectarse, entonces WinRM rechazará todas las demás direcciones o nombres. Si la máquina desde la que se administra está en un dominio, confiará en todas las máquinas de ese dominio. Si no está en un dominio, o en otro dominio, entonces debe especificar en TrustedHosts la dirección o el nombre de la máquina a la que nos conectaremos. No es necesario agregarnos a nosotros mismos en la máquina a la que nos estamos conectando.

La ayuda contiene comandos, los modifiqué ligeramente en un script
################################################################################################################################################################################################# # ################################# # agrega NewHost a la lista TrustedHost con filtrado si dicha línea ya existe # puedes sacar línea de comando especificando el parámetro directamente, por ejemplo #. \ Add-TrustedHost.ps1 192.168.2.1 ################################ # ############################################### # param ($ NewHost = "192.168.2.89") Write-Host "agregando host: $ NewHost" $ prev = (get-item WSMan: \ localhost \ Client \ TrustedHosts) .value if (($ prev.Contains ($ NewHost )) -eq $ false) (if ($ prev -eq "") (set-item WSMan: \ localhost \ Client \ TrustedHosts -Value "(! LANG: $ NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$ prev, $ NewHost" } } Write-Host "" Write-Host "Now TrustedHosts contains:" (get-item WSMan:\localhost\Client\TrustedHosts).value !}
comprueba si existe tal entrada, si no, la agrega a la lista. Puede llamar desde la línea de comando especificando la dirección o el nombre.

Es importante indicar un nombre o una dirección. Si solo hay una dirección en TrustedHosts, no funcionará abrir una sesión por nombre y viceversa; si especifica un nombre, no funcionará adjuntar a la dirección. Considera esto.

cual es la diferencia

Enable-PSRemoting hace más que "winrm quickconfig". El cmdlet Set-WSManQuickConfig hace exactamente lo mismo que "winrm quickconfig". Enable-PSRemoting ejecuta Set-WSManQuickConfig al configurar el sistema

Conexiones remotas
1. Sesiones 1 a 1
abierto por el equipo
Prueba Enter-PSSession -ComputerName
Obtendrá un shell en la máquina remota. Puede conectarse a sí mismo especificando localhost. Los créditos alternativos se especifican con el parámetro -Credencial, la salida la realiza el cmdlet Salir-PSSession

Las restricciones son las siguientes:

no puede hacer un segundo salto: solo 1 sesión, no puede conectarse más dentro de la sesión
no puedes usar comandos que tienen interfaz grafica... Si hace esto, el shell se colgará, presione Ctrl + C para colgar
no puede ejecutar comandos que tengan su propio shell, por ejemplo, nslookup, netsh
puede ejecutar scripts si la política de lanzamiento en la máquina remota les permite ejecutarlos
no se puede adjuntar a una sesión interactiva, inicia sesión como "inicio de sesión de red" como si se aferrara a unidad de red... Por lo tanto, las secuencias de comandos de inicio de sesión no se iniciarán y es posible que no obtenga la carpeta de inicio en la máquina remota (una razón adicional para no asignar carpetas de inicio con secuencias de comandos de inicio de sesión)
no podrá interactuar con el usuario en la máquina remota incluso si está conectado allí. No podrás mostrarle la ventana ni imprimirle nada.

este método es el mejor para operaciones simples, inicie sesión, agite el servidor y desconecte. Si necesita mantener variables en el alcance, necesita una operación larga (muchas horas o días), necesita más opciones de administración, entonces necesita usar una técnica más avanzada.

Un comentario.
los objetos transmitidos a través de la red se cortan y dejan de estar vivos. Sus métodos se eliminan, las propiedades permanecen. Colocar el objeto en su automóvil, conjurarlo y volver a colocarlo no funcionará. Si necesita escribir más, lo agregaré por separado.

2. Sesiones de 1 a muchas
Invocar-Comando
definimos lo que ejecutaremos así:
$ sb = (comandos para la máquina remota separados por punto y coma)
transferencia a máquinas remotas Test1 y Test2
Invocar-Comando -ComputerName Test1, Test2 -ScriptBlock $ sb
se puede lanzar en 32 coches a la vez. Si hay créditos alternativos, utilice el parámetro -Credential

Para pasar el script completo en lugar del parámetro -ScriptBlock, escriba -FilePath, la máquina remota NO necesita tener acceso al archivo, se analizará en partes, se transferirá a través de HTTP y se ejecutará desde el otro lado.

Recuerde que habrá un nuevo alcance en el otro lado, por lo que su script no recibirá valores de su consola, y las variables del script pueden estar vacías en ese lado. Por lo tanto, transfiera instrucciones y scripts listos para usar con parámetros a la vez.

Para utilizar Invoke-Command por completo, debe poder convertir líneas en bloques de script. Por ejemplo, tiene comandos que dependen de alguna lista, necesita generar una cadena, convertirla en un ScriptBlock y enviarla a una computadora remota:
$ sb = :: Crear ($ SomeString)

kuda78
El artículo pierde una muy punto importante- pasar parámetros a un script en una máquina remota.
$ deployRemote = (
param
$ targetEnvName,
$ targetUsername)
$ Global: ErrorActionPreference = "Detener"
#…
}
Invoke-Command -Session $ session -ScriptBlock $ deployRemote -ArgumentList ($ targetEnvName, $ targetUsername)

Sí, de hecho se perdió. Lo hice deliberadamente para no saturar la revisión con parámetros y descripciones. Gracias. El parámetro -ArgumentList funciona tanto con bloques de script como con scripts

3. Sesiones
Es entonces cuando se crea una copia de la pieza desde el otro lado, que está constantemente colgando en la memoria, y se le envían comandos. Como resultado, puede volver a conectarse a él, leer una ejecución larga para su ejecución, aferrarse a diferentes scripts o diferentes usuarios. Por ejemplo, tiene un conjunto de scripts que resuelven una tarea en partes, cada uno de ellos a su vez puede conectarse a una sesión remota, ver los resultados de los comandos anteriores, tener un módulo cargado, variables comunes, un entorno común, hasta la sesión está cerrado a la fuerza.

La sesión se crea usando el cmdlet New-PSSession, el resultado se puede colocar en una variable
$ DC01 = New-PSSession -ComputerName DC01 $ Controladores = New-PSSession DC01, DC02, DC03
puede utilizar los mismos parámetros de conexión que en Invoke-Command

Cómo utilizar:
si 1 a 1
Enter-PSSession -Session $ DC01
si 1 a muchos
Invocar-Comando-Sesiones $ Controladores -ScriptBlock (get-eventlog -logname security -newest 50)
puede ver qué sesiones están abiertas usando Get-PSSession, cierre Remove-PSSession
cerrar todas las sesiones por completo
Get-PSSession | Eliminar-PSSession
puede conectarse a la sesión usando Connect-PSSession, desconectarse a través de Disconnect-PSSession

Invoke-Command puede crear inmediatamente una sesión desconectada, envía comandos para su ejecución y desconecta, luego puede conectarse y descargar los resultados del trabajo. Esto se hace con el parámetro -Disconnected. Recuperar resultados mediante el cmdlet Recieve-PSSession.

Las sesiones tienen muchas configuraciones, incluso es posible crear sesiones con un conjunto truncado de comandos, módulos, etc. Puntos finales personalizados llamados