Удаленный запуск скрипта powershell

Удаленный запуск скрипта powershell

В Powershell есть несколько методов удаленного подключения. Это через:

Сегодня мы поговорим о PS remoting/WinRM. В его состав входит, в основном, два командлета — это:

Этот командлет устанавливает сессию c удаленным компьютером и мы сможем работать прям на нем. Если сравнивать с Linux, то это почти одно и то же:

И второй командлет, который нужен для удаленного выполнения команд как на одном, так и сотни компьютеров:

Где:
-ComputerName — имена компьютеров (или одного)
-Scriptblock — скрипт или командлет в скобках <>

Если опять же сравнить с Linux ssh, то это почти одно и то же:

Как настроить удаленное управление через Powershell?

Для того что бы суметь настроить нужно понять как это работает. Команды выше могут работать по протоколу HTTP (по порту 5985) и HTTPS (5986), за исключением версии Powershell 1.0, который работал в XP (там порт 80/443). По умолчанию у нас стоит HTTP, но и эти данные шифруются используя симметричный ключ AES-256. Сама аутентификация работает в 2 режимах NTLM и Kerberos(по умолчанию стоит он). Если у вас сеть с домен контроллером, т.е. есть Kerberos, то у вас должны работать команды выше. Если компьютеры в Workgroup, то они используют NTLM и для этого нужна дополнительная настройка. Кроме того, если вы вместо имен используете IP, то вы в любом случае используете NTLM и это по умолчанию не работает.

Если у вас не работают команды выше нужно проверить запущен ли сервис WinRM на том компьютере, к которому мы хотим подключиться:

Если не запушен:

В этом случае мы ставим запуск сервиса автоматически и настраиваем winrm в дефолтной конфигурации. Этот сервис дает возможность принимать команды Powershell и устанавливать сеансы.

Если вы работаете под профилем сети "Public" (не "Domain" или "Private"), то нужно выполнить еще один командлет, разрешающий работать в таких сетях:

Если мы выполним такую команду:

Получим ошибку:
Connecting to remote server 192.168.3.100 failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided.

Которая говорит, что мы можем подключится по IP если используем HTTPS (для этого нужен сертификат) или добавить хост, к которому подключаемся в TrustedHost компьютера с которого хотим запустить команду. Для этого делаем:

После этого все будет работать, но команды должны исполняться с переменной, в которой будут лежать учетные данные пользователя. Т.е. так:

Где:
$cred — это переменная, куда мы сохраняем данные с формы Get-Credential
-Credential — сюда мы передаем переменную

Так же отмечу, что все команды, которые мы запускаем для удаленного выполнения через Poweshell, должны происходить от члена группы Администратора того хоста, к которому мы подключаемся.

Теперь мы можем устанавливать множество сессий с помощью командлета:

Получать ID этих сессий:

И подключаться по этим ID:

Или использовать с invoke существующую сессию, а командлет для удаленного компьютера запускать с файла:

А так же, т.к. WinRM настроен, выполнять командлеты где есть ключ -ComputerName, сразу на нескольких компьютерах. Этот командлет пропингует AD сразу с нескольких компьютеров:

Или же использовать методы описанные выше.

Дополнительные ключи мы можем узнать по командлетам:

Одна команда Windows PowerShell позволяет запускать команды на одном или сотнях компьютеров. You can run commands on one or hundreds of computers with a single PowerShell command. Windows PowerShell поддерживает удаленное вычисление с помощью разных технологий, включая WMI, RPC и WS-Management. Windows PowerShell supports remote computing by using various technologies, including WMI, RPC, and WS-Management.

PowerShell Core поддерживает инструментарий WMI, WS-Management и удаленное взаимодействие через SSH. PowerShell Core supports WMI, WS-Management, and SSH remoting. RPC больше не поддерживается. RPC is no longer supported.

Дополнительные сведения об удаленном взаимодействии в PowerShell Core см. в следующих статьях: For more information about remoting in PowerShell Core, see the following articles:

Удаленное взаимодействие с Windows PowerShell без настройки Windows PowerShell Remoting Without Configuration

Многие командлеты Windows PowerShell имеют параметр ComputerName, который позволяет собирать данные и изменять параметры одного или нескольких удаленных компьютеров. Many Windows PowerShell cmdlets have the ComputerName parameter that enables you to collect data and change settings on one or more remote computers. Эти командлеты используют разные протоколы связи и работают во всех операционных системах Windows без специальной настройки. These cmdlets use varying communication protocols and work on all Windows operating systems without any special configuration.

В эти командлеты входят следующие: These cmdlets include:

Читайте также:  Почему принтер не хочет сканировать

Обычно командлеты, которые поддерживают удаленное взаимодействие без специальной настройки, имеют параметр ComputerName, но не имеют параметра Session. Typically, cmdlets that support remoting without special configuration have the ComputerName parameter and don’t have the Session parameter. Чтобы найти эти командлеты в сеансе, введите: To find these cmdlets in your session, type:

Служба удаленного взаимодействия Windows PowerShell Windows PowerShell Remoting

Благодаря использованию протокола WS-Management служба удаленного взаимодействия Windows PowerShell позволяет запустить любую команду Windows PowerShell на одном или нескольких удаленных компьютерах. Using the WS-Management protocol, Windows PowerShell remoting lets you run any Windows PowerShell command on one or more remote computers. Вы можете устанавливать постоянные подключения, запускать интерактивные сеансы и выполнять скрипты на удаленных компьютерах. You can establish persistent connections, start interactive sessions, and run scripts on remote computers.

Чтобы использовать службу удаленного взаимодействия Windows PowerShell, удаленный компьютер должен быть настроен для удаленного управления. To use Windows PowerShell remoting, the remote computer must be configured for remote management. Дополнительные сведения, в том числе инструкции, см. в разделе about_Remote_Requirements. For more information, including instructions, see About Remote Requirements.

После настройки службы удаленного взаимодействия Windows PowerShell вы получите доступ ко многим стратегиям удаленного взаимодействия. Once you have configured Windows PowerShell remoting, many remoting strategies are available to you. В этой статье перечислены только некоторые из них. This article lists just a few of them. См. дополнительные сведения об удаленном взаимодействии. For more information, see About Remote.

Запуск интерактивного сеанса Start an Interactive Session

Чтобы запустить интерактивный сеанс с одним удаленным компьютером, используйте командлет Enter-PSSession. To start an interactive session with a single remote computer, use the Enter-PSSession cmdlet. Например, чтобы запустить интерактивный сеанс с удаленным компьютером Server01, введите: For example, to start an interactive session with the Server01 remote computer, type:

В командной строке отобразится имя удаленного компьютера. The command prompt changes to display the name of the remote computer. Все команды, введенные в командной строке, запускаются на удаленном компьютере, а результаты отображаются на локальном компьютере. Any commands that you type at the prompt run on the remote computer and the results are displayed on the local computer.

Чтобы завершить интерактивный сеанс, введите: To end the interactive session, type:

См. дополнительные сведения о командлетах Enter-PSSession и Exit-PSSession: For more information about the Enter-PSSession and Exit-PSSession cmdlets, see:

Выполнение удаленной команды Run a Remote Command

Чтобы выполнить команду на одном или нескольких компьютерах, используйте командлет Invoke-Command. To run a command on one or more computers, use the Invoke-Command cmdlet. Например, чтобы выполнить команду Get-UICulture на удаленных компьютерах Server01 и Server02, введите: For example, to run a Get-UICulture command on the Server01 and Server02 remote computers, type:

Выходные данные будут возвращены на ваш компьютер. The output is returned to your computer.

Запуск сценария Run a Script

Чтобы запустить скрипт на одном или нескольких удаленных компьютерах, используйте параметр FilePath командлета Invoke-Command . To run a script on one or many remote computers, use the FilePath parameter of the Invoke-Command cmdlet. Сценарий должен быть включен или доступен для локального компьютера. The script must be on or accessible to your local computer. Результаты будут возвращены на локальный компьютер. The results are returned to your local computer.

Например, следующая команда выполняет скрипт DiskCollect.ps1 на удаленных компьютерах Server01 и Server02. For example, the following command runs the DiskCollect.ps1 script on the remote computers, Server01 and Server02.

Установка постоянного подключения Establish a Persistent Connection

Используйте командлет New-PSSession для создания постоянного сеанса на удаленном компьютере. Use the New-PSSession cmdlet to create a persistent session on a remote computer. В следующем примере создаются удаленные сеансы на удаленных компьютерах Server01 и Server02. The following example creates remote sessions on Server01 and Server02. Объекты сеанса хранятся в переменной $s . The session objects are stored in the $s variable.

После установки сеансов в них можно выполнить любую команду. Now that the sessions are established, you can run any command in them. Так как сеансы являются постоянными, вы можете собирать данные из одной команды и использовать их в другой. And because the sessions are persistent, you can collect data from one command and use it in another command.

Например, следующая команда выполняет команду Get-Hotfix в сеансах в переменной $s и сохраняет результаты в переменной $h. For example, the following command runs a Get-HotFix command in the sessions in the $s variable and it saves the results in the $h variable. Переменная $h создается в каждом сеансе в переменной $s, но она не существует в локальном сеансе. The $h variable is created in each of the sessions in $s, but it doesn’t exist in the local session.

Читайте также:  Расчетный адрес карты сбербанка где посмотреть

Теперь вы можете использовать данные в переменной $h с другими командами в том же сеансе. Now you can use the data in the $h variable with other commands in the same session. Результаты отобразятся на локальном компьютере. The results are displayed on the local computer. Например: For example:

Расширенная служба удаленного взаимодействия Advanced Remoting

Это и есть служба удаленного взаимодействия Windows PowerShell. Windows PowerShell remote management just begins here. Используя командлеты, установленные с Windows PowerShell, можно установить и настроить удаленные сеансы с локальных и удаленных компьютеров, создать настраиваемые и ограниченные сеансы, разрешить пользователям импортировать команды из удаленного сеанса, которые могут неявно выполняться в удаленном сеансе, настроить безопасность удаленного сеанса и многое другое. By using the cmdlets installed with Windows PowerShell, you can establish and configure remote sessions both from the local and remote ends, create customized and restricted sessions, allow users to import commands from a remote session that actually run implicitly on the remote session, configure the security of a remote session, and much more.

Windows PowerShell включает поставщик WSMan. Windows PowerShell includes a WSMan provider. Поставщик создает диск WSMAN: , который позволяет перемещаться по иерархии параметров конфигурации на локальном и удаленном компьютерах. The provider creates a WSMAN: drive that lets you navigate through a hierarchy of configuration settings on the local computer and remote computers.

См. дополнительные сведения о поставщике WSMan и командлетах WS-Management или введите команду Get-Help wsman в консоли Windows PowerShell. For more information about the WSMan provider, see WSMan Provider and About WS-Management Cmdlets, or in the Windows PowerShell console, type Get-Help wsman .

Дополнительная информация: For more information, see:

Справку по ошибкам службы удаленного взаимодействия см. в статье about_Remote_Troubleshooting. For help with remoting errors, see about_Remote_Troubleshooting.

Здесь минимум теории, в основном практическая часть. Описывается как настроить WinRM, как изменить профиль сетевого адаптера, дается скрипт по добавлению в TrustedHosts с фильтрацией, объясняется зачем нужны доверенные хосты, и рассматриваются поверхностно удаленные подключения так чтобы можно было сесть и сразу админить удаленные машины.

Наиболее простой путь сконфигурировать удаленное управление это выполнить Enable-PSRemoting в оболочке powershell с правами администратора. При этом произойдет следущее:

  • запустится служба WinRM (если запущена перезапустится)
  • служба WinRM перейдет в состояние — автоматический запуск при старте
  • будет создан прослушиватель WinRM для HTTP трафика на порту 5985 для всех локальных IP адресов
  • будет создано правило файрвола для прослушивателя WinRM. Внимание, этот пункт завершится с ошибкой если любая из сетевых карточек имеет тип сети «публичная», т.к. открывать порт на такой карточке не хорошо. Если у вас при конфигурировании вышла такая ошибка измените профиль это сетевушки командлетом Set-NetConnectionProfile и после этого запустите Enable-PSRemoting снова. Если вам нужна сетевая карточка с профилем «Публичная сеть» запустите Enable-PSRemoting с параметром -SkipNetworkProfileCheck в этом случае будут созданы правила файрвола только из локальной сети.

После этого нужно разрешить подключаться к удаленной машине с той машины с которой будет происходить управление. Сделано это в целях безопасности для того чтобы уменьшить риск взлома сессии удаленного управления или DNS с подстановкой себя вместо удаленной машины и предотвратить исполнение скриптов на машинах которые вы принудительно не разрешили.

для проверки куда можно подключаться используем:

для разрешения подключаться ко всем

Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

в хелпе указаны команды, я их чуть чуть переделал в скрипт

он проверяет на есть ли такая запись, если нет то добавляет в список. Вызывать можно из командной строки указав адрес или имя.

Есть разница указывать имя или адрес. Если в TrustedHosts будет только адрес то открыть сессию по имени не получится, и наоборот — если указать имя то прицепится по адресу не получится. Учитывайте это.

Читайте также:  Как оформить объявление на авито бесплатно

Часто встречается ссылка на команду

это не тоже самое что Enable-PSRemoting

Enable-PSRemoting делает больше действий чем «winrm quickconfig». Командлет Set-WSManQuickConfig делает точно такие же действия как «winrm quickconfig». Enable-PSRemoting запускает Set-WSManQuickConfig когда ведет настройку системы

Set-WSManQuickConfig делает следущие действия:

  1. запускат WinRM сервис
  2. устанавливает автостарт службы WinRM в автоматический
  3. создает прослушиватель
  4. добавляет исключения файрвола

Enable-PSRemoting кроме этого делает еще следущее

  1. включает все зарегистрированные конфигурации сессий PowerShell для получения инструкций от удаленных машин
  2. регистрирует конфигурацию если она не зарегистрирована «Microsoft.PowerShell»
  3. регистрирует конфигурацию если она не зарегистрирована «Microsoft.PowerShell32» на 64 битных машинах
  4. убирает запрет «Deny Everyone» из дескриптора безопасности всех конфигураций сессий
  5. перезапускает сервис WinRM

источник
Enable-PSRemoting TechNet
Set-WSManQuickConfig TechNet

Удаленные подключения
1. Сессии 1-to-1
открываются командой

Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential, выход происходит командлетом Exit-PSSession

Ограничения следующие:

  • нельзя сделать второй прыжок — только 1 сессия, внутри сессии подключиться дальше нельзя
  • вы не можете использовать команды имеющие графический интерфейс. Если вы это сделаете оболочка повиснет, нажмите Ctrl+C чтобы отвисло
  • вы не можете запускать команды имеющие свой собственый шел, например nslookup, netsh
  • вы можете запускать скрипты если политика запуска на удаленной машине позволяет их запускать
  • нельзя прицепится к интерактивной сессии, вы заходите как «network logon», как будто прицепились к сетевому диску. Поэтому не запустятся логон скрипты, и вы можете не получить домашнюю папку на удаленной машине (лишний довод чтобы не мапать хом фолдеры логон скриптами)
  • вы не сможете взаимодействовать с юзером на удаленной машине даже если он туда залогинен. Не получится показать ему окошко или попечатать чтонибудь ему.

этот способ лучше всего для простых операций, зашел, подергал сервер и отключился. Если нужно удержать переменные в скопе, нужна длительная операция (много часов или дней), нужно больше возможностей по администрированию то нужно использовать технику попродвинутее.

Комментарий.
объекты переданные по сети обрезаются и перестают быть живыми. У них удаляются методы, свойства остаются. Вытащить объект на свою машину, поколдовать и засунуть обратно не получится. Если нужно больше пишите, допишу отдельно.

2. Сессии 1-to-many

определяем что будем исполнять так:

передаем на удаленные машины Test1 и Test2

за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

Чтобы передать целиком скрипт вместо параметра -ScriptBlock пишем -FilePath, удаленной машине НЕ нужно иметь доступ к файлу, он будет разобран на запчасти, передан через HTTP и выполнен с той стороны.

Запомним что на той стороне будет новый скоп, так что ваш скрипт не получит значений из вашей консоли, а переменные скрипта могут оказаться на той стороне пустыми. Поэтому передавайте сразу целиком готовые инструкции и скрипты с параметрами.

для полноценного использования Invoke-Command надо уметь превращать строки в скрипт блоки. Например у вас есть команды которые зависят от какогото списка, вам нужно сгенерировать строку, превратить ее в ScriptBlock и отправить на удаленный комп:

kuda78
В статье пропущен очень важный момент — передача параметров в скрипт на удаленной машине.

$deployRemote = <
param(
[string]$targetEnvName,
[string]$targetUsername)
$Global:ErrorActionPreference = «Stop»
#…
>

Invoke-Command -Session $session -ScriptBlock $deployRemote -ArgumentList ($targetEnvName, $targetUsername)

Да действительно пропущен. Сделал сознательно чтобы не загромождать обзор параметрами и описаниями. Спасибо. Параметр -ArgumentList работает как со скрипт блоками так и со сценариями

3. Сессии
Это когда с той стороны создается копия пошика постоянно висящая в памяти, и в нее отправляются команды. Как результат к ней можно переподключится, ченить долгое запустить на исполнение, цепляться из разных скриптов или разными юзерами. Например у вас есть набор скриптов решающих одну задачу по частям, каждый из них поочереди может подключатся к одной удаленной сессии, видеть результаты работы предыдущих команд, иметь одни загруженные модули, общие переменные, общее окружение, до тех пор пока сессия не будет принудительно закрыта.

Создание сессии происходит командлетом New-PSSession, результат можно поместить в переменную

использовать можно такие же параметры подключения как в Invoke-Command

Как использовать:
если 1-to-1

посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession
закрыть вообще все сессии

прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

Invoke-Command может создать сразу disconnected сессию, он отправляет команды на исполнение и отключатся, позже можно подключится и сгрузить результаты работы. Делается это параметром -Disconnected. Получение результатов через командлет Recieve-PSSession.

Сессии имеют очень много настроек, возможно даже создание сессий с обрезаным набором команд, модулей и т.п. Называется custom endpoints

Ссылка на основную публикацию
Adblock detector