Настройка удаленного взаимодействия в PowerShell (часть 1). Удаленное управление powershell

Настройка удаленного взаимодействия в PowerShell

Настройка удаленного взаимодействия в PowerShell (часть 1)

Чтобы обеспечить возможность удаленного взаимодействия с помощью PowerShell, необходимо произвести некоторые настройки. Количество этих настроек зависит от операционной системы, сетевого окружения, требований к безопасности (и еще бог знает чего). Поскольку настроек довольно много, я попробую рассказать о наиболее важных из них. Ну, поехали…

Включение удаленного управления

Для того, чтобы управлять удаленным компьютером, необходимо на этом компьютере удаленное взаимодействие разрешить. Исключение составляет Windows Server 2012, где все возможности удаленного управления включены по умолчанию. Для всех остальных операционных систем надо:

1. Стартовать службу WinRM и поставить ее на автозапуск;2. Создать прослушиватель (listener), который будет слушать запросы на управление;3. Включить на файерволе правило, разрешающее трафик WS-Management.

Для настройки одного компьютера проще всего использовать командлет Enable-PSRemoting. Он произведет все необходимые действия, а также зарегистрирует конфигурации сессии по умолчанию. Для того, чтобы подавить запросы на подтверждение, можно добавить параметр -force. Консоль необходимо запустить с правами администратора, иначе будет выдана ошибка.

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

В разделе Computer Configuration\Policies\Windows Settings\System Services включим политику «Windows Remote Management (WS-Management)». Она задает режим запуска для службы WinRM.

В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включаем политику «Allow automatic configuration of listeners», которая создает прослушиватель на порту 5985 (порт для HTTP по умолчанию). Дополнительно можно указать, с каких IP можно принимать подключения. Если в фильтрации по IP нет необходимости, просто ставим знак *, что означает принимать подключения с любого адреса.

Затем идем в раздел Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules и создаем новое правило. Выбираем пункт Predefined (Предопределенные правила) и в списке выбираем Windows Remote Management.

Обратите внимание, что можно выбрать два режима работы — стандатный и совместимый. В первом случае будет открыт порт 5985, использующийся WinRM по умолчанию, во втором — порт 80 (для совместимости со старыми версиями WinRM). По умолчанию выбраны оба.

Настройка доверия между компьютерами

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

Если компьютеры являются членами одного домена, или находятся в разных, но доверяющих друг другу доменах, то взаимная аутентификация будет выполнена доменными службами. Главное, чтобы имя компьютера разрешалось в IP-адрес и соответствовало имени компьютера в Active Directory.

Внимание: при подключении нужно указывать действительные имена компьютеров, т.е. так как они указаны в Active Directory. Если компьютер входит в локальный домен, то можно указать просто имя компьютера, например SRV1. Для указания имени компьютера из другого домена надо указать полное доменное имя (FQDN) — SRV1.contoso.com. Если же указать IP-адрес, или некоторое другое DNS-имя (например CNAME алиас), то взаимная аутентификация не сработает.

Если же один или оба компьютера не входят в домен, то для взаимной аутентификации есть два варианта: добавить удаленную машину в список доверенных узлов (Trusted Hosts) или использовать SSL.

Trusted Hosts

Добавление компьютера в Trusted Hosts — путь простой, но менее безопасный. Для компьютеров, находящихся в Trusted Hosts взаимная аутентификация фактически отключена. Поэтому пользоваться этим способом стоит с большой осторожностью.

Добавить компьютер в доверенные узлы можно с помощью PowerShell. Так для того, чтобы создать список доверенных хостов и добавить в него компьютер SRV1 воспользуемся командой:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value SRV1.contoso.com

При добавлении нескольких компьютеров их имена можно перечислить через запятую. Допускается указывать не только имя, но IP-адрес компьютера. Также поддерживаются символы подстановки. Например, можно добавить в доверенные хосты все компьютеры из домена contoso.com, указав значение *.contoso.com, или вообще всех без исключения:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

Чтобы добавить имя компьютера в уже имеющийся список доверенных узлов, необходимо сначала сохранить текущее значение в переменной, а затем присвоить значение разделенному запятыми списку, который включает текущее и новое значения. Например, чтобы добавить компьютер SRV2 в имеющийся список доверенных узлов, воспользуйтесь следующей командой:

$curr = (Get-Item WSMan:\localhost\Client\TrustedHosts).value Set-Item WSMan:\localhost\Client\TrustedHosts -Value ″$curr,SRV2.contoso.com″

Ну и посмотреть список доверенных узлов можно командой:

Get-Item WSMan:\localhost\Client\TrustedHosts

Также для добавления в TrustedHosts можно воспользоваться групповой политикой. В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Client включаем политику «Trusted Hosts» и добавляем имена или IP-адреса компов через запятую. Поддерживаются подстановочные символы.

Примечание: если TrustedHosts сконфигурированы через GPO, то из PS изменить их не удастся. То же касается и всех остальных настроек PS Remoting.

SSL

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

Во первых, для использования этого метода, нам нужен цифровой сертификат SSL для машины, к которой мы собираемся подключаться. Получение сертификата — отдельная тема, не будем на ней останавливаться. В тестовой среде я воспользуюсь утилитой Makecert, входяшей в состав Windows SDK, и создам самоподписанный сертификат:

makecert -a sha1 -r -pe -n ″CN=wks8″ -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp ″Microsoft RSA SChannel Cryptographic Provider″ -sy 12 -m 12 ″C:\myssl.cer″

Эта команда создаст SSL-сертификат сроком на год и поместит его в хранилище сертификатов локального компьютера. Обратите внимание, что сертификат должен быть выдан на то же имя, которое вы будете указывать в команде подключения.

После получения сертификат должен быть добавлен в Trusted Root Authority (доверенные корневые центры сертификации). Для этого открываем сертификат и жмем на кнопку «Установить сертификат».

Запускается мастер импорта сертификатов. Указываем расположение хранилища «Локальный компьютер».

В качестве хранилища выбираем «Доверенные корневые центры сертификации».

Теперь наш сертификат является доверенным. Еще раз открываем его, и на вкладке «Состав» находим отпечаток сертификата (CertificateThumbprint). Копируем его в буфер обмена.

Теперь можно создавать прослушиватель для HTTPS. Открываем консоль PowerShell и вводим команду:

New-WSManInstance winrm/config/listener -SelectorSet @{ Address=′*′; Transport=′HTTPS′ } -ValueSet @{ HostName=′wks8′; CertificateThumbrint=′xxx′}

В поле CertificateThumbrint вставляем отпечаток сертификата, скопированный в предыдущем пункте.

Исключения файерволла Windows (если он включен) для нового прослушивателя необходимо настраивать вручную, автоматически они не создадутся. Поэтому создадим новое правило для входящего трафика по портам TCP 5986 и 443:

New-NetFirewallRule -DisplayName ″Windows Remote Management (HTTPS)″ -Direct Inbound -Protocol TCP -LocalPort 5986,443 -Action Allow -Enabled True

Также для создания правила можно воспользоваться графической оснасткой или утилитой командной строки netsh, кому что больше нравится.

Далее идем на компьютер SRV1, с которого будем подключаться. Поскольку я использую самоподписанный сертификат, то его придется добавить к доверенным корневым сертификатам и на клиенте. Копируем файл сертификата myssl.cer на SRV1 и устанавливаем командой:

certutil -addstore root C:\myssl.cer

Вот и все, настройка закончена. Теперь можно подключаться. Откроем интерактивную сессию на wks8 командой:

Enter-PSSession -ComputerName wks8 -Credential wks8\kirill -UseSSL

Обратите внимание, что при подключении по SSL необходимо вводить учетные данные, а также указывать тип подключения. Дальше все как обычно.

Отключение проверки

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

В принципе это правильно, но при необходимости проверки можно отменить. Для этого в свойствах сессии есть два параметра:

-SkipCACheck — отменяет проверку издателя сертификата;-SkipCNCheck — отменяет проверку соответствия имени компьютера.

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

$option = New-PSSessionOption -SkipCACheck -SkipCNCheckEnter-PSSession -ComputerName wks8 -SessionOption $option -Credential wks8\kirill -UseSSL

Правда в этом случае теряется смысл SSL-сертификатов, и тогда уж проще пользоваться Thrusted Hosts. Но возможность такая есть, и знать о ней надо.

Дополнительные настройки

Начиная со второй версии, WinRM по умолчанию слушает порт 5985 для HTTP и 5986 для HTTPS. Для совместимости со старыми версиями (или чтобы не открывать дополнительные порты на брандмауэре) можно дополнительно включить прослушиватели на традиционных портах 80 и 443. Для HTTP:

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener $true

И для HTTPS:

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener $true

То же самое можно сделать с помощью групповых политик. Для этого надо в разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включить политики «Turn On Compatibility HTTP Listener» и «Turn On Compatibility HTTPS Listener».

Порты по умолчанию можно изменить и указать слушать любой нестандартный порт, например порт 8080:

Set-Item WSMan:\localhost\listener\listener*\port -Value 8080

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

На этом все. Во второй части статьи рассмотрим конфигурации удаленных сессий, создание конечных точек (endpoint), ну и что нибудь еще по мелочи 🙂

windowsnotes.ru

Удаленное управление Exchange - Get-PowerShell

Для настройки Exchange 2013 в основном используется два инструмента это Exchange Admin Center и Exchange Managment Shell. Использование Admin Center удаленно — не проблема. Это веб сайт, который можно открыть на любом компьютере. Удаленное управление Exchange с использованием Managment Shell, требует установки этого Managment Shell. Однако большинство задач можно выполнить просто удаленно подключившись к Exchange 2013.

Для выполнения команд Exchnage удаленно необходимо в общем-то создать сессию и импортировать командлеты из этой сессии в текущий сеанс PowerShell

Запуск команд удаленно

Данный подход позволяет запустить команды Exchange с компьютера, на котором не установлен Exchange удаленно.

Во-первых, запускаем обычный повершел (конечно не ниже третьей версии).

Во-вторых, запускаем следующий командлет, он создаст подключение (сессию), которое мы в дальнейшем будем использовать для удаленного управления Exchnage.

PS D:\> $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://lon-cas1.adatum.com/powersh ell/ -Authentication Kerberos

PS D:\> $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://lon-cas1.adatum.com/powersh

ell/ -Authentication Kerberos

Где вместо lon-cas1.adatum.com вы указываете свой сервер клиентского доступа, конкретный URI можно посмотреть в том же Exchange Admin Center в разделе серверы -> виртуальные директории (servers -> virtual directories).

Данная сессия будет создана с разрешениями текущего пользователя, если желаете запустить с разрешениями другого пользователя выполните командлет с параметром -credential

PS D:\> $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://lon-cas1.adatum.com/powersh ell/ -Authentication Kerberos -Credential (Get-Credential)

PS D:\> $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://lon-cas1.adatum.com/powersh

ell/ -Authentication Kerberos -Credential (Get-Credential)

Вариант выше создаст сессию, спросив предварительно в отдельном окне логин и пароль.

В-третьих, начните использовать сессию.

PS D:\> Import-PSSession $session -DisableNameChecking ModuleType Name ExportedCommands ---------- ---- ---------------- Script tmp_wfdf152x.m3e {Add-ADPermission, Add-AvailabilityAddressSpace, Add-ContentFilterPhr...

PS D:\> Import-PSSession $session -DisableNameChecking

ModuleType Name ExportedCommands

---------- ---- ----------------

Script tmp_wfdf152x.m3e {Add-ADPermission, Add-AvailabilityAddressSpace, Add-ContentFilterPhr...

После чего можно вводить команды Exchange Managment Shell.

PS D:\> Get-ExchangeServer Name Site ServerRole Edition AdminDisplayVersion ---- ---- ---------- ------- ------------------- LON-MBX1 Adatum.com/Config... Mailbox Enterprise Version 15.0 (Bu... LON-MBX2 Adatum.com/Config... Mailbox Enterprise Version 15.0 (Bu... LON-CAS1 Adatum.com/Config... ClientAc... Enterprise Version 15.0 (Bu... LON-CAS2 Adatum.com/Config... ClientAc... Enterprise Version 15.0 (Bu...

PS D:\> Get-ExchangeServer

Name Site ServerRole Edition AdminDisplayVersion

---- ---- ---------- ------- -------------------

LON-MBX1 Adatum.com/Config... Mailbox Enterprise Version 15.0 (Bu...

LON-MBX2 Adatum.com/Config... Mailbox Enterprise Version 15.0 (Bu...

LON-CAS1 Adatum.com/Config... ClientAc... Enterprise Version 15.0 (Bu...

LON-CAS2 Adatum.com/Config... ClientAc... Enterprise Version 15.0 (Bu...

Вообще удаленное управление Exchange все же отличается от использование Exchange Managment Shell. Поэтому если вы планируете постоянное управление с данного компьютера — рекомендуется поставить Management Tools для Exchnage.

В-четвертых, после использования всех необходимых команд. Разорвите сессию.

PS D:\> Remove-PSSession $session

Полезные ссылки

Подключение к удаленному серверу статья на technet

Справка по использованию Import-PSSession

get-powershell.ru

Удаленное управление PowerShell

Локальная настройка PowerShell для удаленного управления

PS C:\> Enable-PSRemoting # Командлет сконфигурирует и запустит службу WinRM для удаленного управления PowerShell; добавит в исключение Windows Firewall порт для службы WinRM TCP 5985 WinRM Quick Configuration Running command "Set-WSManQuickConfig" to enable this machine for remote management through WinRM service. This includes: 1. Starting or restarting (if already started) the WinRM service 2. Setting the WinRM service type to auto start 3. Creating a listener to accept requests on any IP address 4. Enabling firewall exception for WS-Management traffic (for http only). Do you want to continue? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y WinRM has been updated to receive requests. WinRM service type changed successfully. WinRM service started. WinRM has been updated for remote management. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. WinRM firewall exception enabled. Confirm Are you sure you want to perform this action? Performing operation "Registering session configuration" on Target "Session configuration "Microsoft.PowerShell32" is not found. Running command "Register-PSSessionConfiguration Microsoft.PowerShell32 -processorarchitecture x86 -force" to create "Microsoft.PowerShell32" session configuration. This will restart WinRM service.". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping... WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping... WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping... PS C:\>

Настройка через Групповые политики Active Directory удаленного управления PowerShell

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

Включить автоматическое конфигурирование службы WinRM
Добавить исключение в Windows Firewall для порта TCP 5985

Создаем Group Policy Object

[Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service/]

Параметр Allow automatic configuration of listeners устанавливаем в Enabled и указываем с каких IP-адресов серверу WinRM разрешается принимать соединения (* - с любых адресов, пустое поле - не принимать соединения, рис.1).

[Сomputer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/]

Добавляем новое правило: можно воспользоваться предустановленным параметром Predefined (рис.2) при этом снимаем галочку в окне настроек "Windows Remote Management - Compatibility Mode (HTTP-In)" и затем, если необходимо, добавляем правилу настройки Scope, чтобы указать с каких именно IP-адресов разрешается подключение (рис.3)

Управление удаленным хостом с помощью PowerShell

Терминальные сеансы PowerShell

Подключаемся по имени хоста внутри домена

PS C:\> whoami # узнаем под каким пользователем мы сейчас работаем domain\user01 PS C:\> Enter-PSSession -ComputerName remotehost33.domain.local -Credential domain\admin # устанавливаем соединение с удаленным хостом remotehost33, используя альтернативные учетные данные [remotehost33.domain.local]: PS C:\> # как видно из приглашения командной строки, мы уже управляем удаленным компьютером [remotehost33.domain.local]: PS C:\> whoami # узнаем под каким пользователем мы работаем в удаленном сеансе domain\admin [remotehost33.domain.local]: PS C:\> exit # завершаем удаленный сеанс PS C:\> # мы снова на локальном хосте

Подключаемся по IP-адресу

Здесь есть небольшой подвох. Для подключения через WinRM по IP необходимо чтобы удовлетворялись следующие условия:

транспортным протоколом является HTTPS или назначением является узел из списка TrustedHosts;
должны быть явно указанны учетные данные для соединения,

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

PS C:\> Enter-PSSession -ComputerName 10.14.1.100 -Credential domain\admin # Получаем ошибку, потому как IP-адрес, к которому мы коннектимся не добавлен в доверенные хосты и мы не используем ключ -UseSSL (необходима настройка сертификатов) Enter–PSSession : Connecting to remote server 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. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:16 + Enter–PSSession <<<< –ComputerName 10.14.1.100 –Credential domain\admin + CategoryInfo : InvalidArgument: (10.14.1.100:String) [Enter–PSSession], PSRemotingTransportException + FullyQualifiedErrorId : CreateRemoteRunspaceFailed PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts * # Таким образом мы сможем коннектиться к любым хостам (опасно, т.к. наши учетные данные могут утечь в сеть) PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.14.1.100,computer2,computer31" # Так можно добавить сразу несколько хостов в список TrustedHosts PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.14.1.100 # Мы выполним добавление только необходимого нам узла. Также не забываем, что если сетевой маршрут к хосту возможно прослушать сниффером, наши учетные данные могут быть перехвачены. Так что не стоит добавлять в TrustedHosts узлы из интернета WinRM Security Configuration. This command modifies the TrustedHosts list for the WinRM client. The computers in the TrustedHosts list might not be authenticated. The client might send credential information to these computers. Are you sure that you want to modify this list? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y PS C:\> Enter-PSSession -ComputerName 10.14.1.100 -Credential domain\admin # Повторяем команду подключения, которая вначале нам выбивала ошибку [10.14.1.100]: PS C:\> # Как видно, мы успешно соединились по IP

Удаленный вызов

Мы также можем и не устанавливать терминальный сеанс с удаленным компьютером, а лишь только вызвать на нем нужный нам скрипт или команду и локально получить его вывод (удаленный вызов процедур). В этом нам поможет командлет Invoke-Command.

Например, давайте вызовем на локальном, а затем на удаленном компьютере с именем "remotehost33", командлет (Get-WMIObject -Class Win32_OperatingSystem).CSName , который выведает нам имя компьютера, и посмотрим что получится:

PS C:\> (Get-WMIObject -Class Win32_OperatingSystem).CSName LocalHost01 PS C:\> Invoke-Command -ComputerName remotehost33 -Credential domain\admin -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} RemoteHost33 PS C:\> Invoke-Command -ComputerName remotehost33, remotehost34, remoteserv02 -Credential domain\admin -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} # скрипт-блок будет выполнен на трех компьютерах, указанных через запятую. Если после запятой стоит дополнительно символ пробела, то скрипт-блок будет выполнятся поочередно. Если же между именами хостов стоит только запятая без пробелов, то скрипт-блок выполнится в обратной очередности

Работа с сессиями PowerShell

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

PS C:\> New-PSSession -ComputerName remotehost33 -Credential domain\admin # создаем новую сессию Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Session1 remotehost33 Opened Microsoft.PowerShell Available PS C:\> $ssn1 = Get-PSSession -Id 1 # объявляем переменную ssn1 и загоняем в нее нашу сессию с идентификатором №1 PS C:\> Invoke-Command -Session $ssn1 -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} # вызываем удаленную команду, используя вместо имени компьютера параметр -Session с указанием созданной нами переменной ssn1. Учетные данные здесь повторять нельзя, т.к. сессия уже открыта remotehost33 PS C:\> New-PSSession -ComputerName remotehost34,remotehost34 -Credential domain\admin # можно создавать несколько сессий с одним компьютером Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 remotehost34 Opened Microsoft.PowerShell Available 3 Session3 remotehost34 Opened Microsoft.PowerShell Available PS C:\> Get-PSSession # мы видим новые сессии, в добавок к существующей Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Session1 remotehost33 Opened Microsoft.PowerShell Available 2 Session2 remotehost34 Opened Microsoft.PowerShell Available 3 Session3 remotehost34 Opened Microsoft.PowerShell Available PS C:\> Remove-PSSession -ComputerName remotehost34 # удаляем все установленные сессии с компьютером remotehost34 PS C:\> Get-PSSession # проверяем что получилось Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Session1 remotehost33 Opened Microsoft.PowerShell Available PS C:\> Enter-PSSession -Id 1 # помимо удаленного вызова, также можно заходить в установленную сессию терминально, указав ее идентификатор (как в этом примере), или указав переменную с ключем -Session (как я описал выше) [remotehost33]: PS C:\>

Комментарии:

vam.in.ua

Работа с удаленными сессиями Powershell

Не так давно пришлось потратить немного времени на настройку удаленного доступа через Powershell. Мне такой подход кажется очень хорошей альтернативной Remote Desktop Services в ряде случаев (перезапустить сервис на удаленном хостинге VDS, сделать резервные копии, посмотреть состояние системы и т.д.).

Возможность создания удаленных сеансов Powershell появилась в версии 2. Для этого используется командлет Enter-PSSession/Invoke-Command. Однако, перед их использованием следует подготовить среду.

Что делаем на сервере:

Шаг 1: Открываем консоль Powershell и разрешаем удаленные сессии командлетом Enable-PSRemoting с ключом Force.

Enable-PSRemoting -Force

Шаг 2: Убеждаемся в том, что служба WinRM запущена.

Start-Service WinRM

Шаг 3: Настраиваем правила в брэндмауэре, чтобы входящие подключения были возможны.

На компьютере, который будет использоваться как клиентский тоже необходимо выполнить несколько действий:

Шаг 1: Разрешить подключение к удаленным узлам. Для доступа к любым узлам можно воспользоваться следующей конструкцией:

Set-Item wsman:\localhost\client\trustedhosts * -Force

Шаг 2: Убедиться, что брэндмауэр не блокирует исходящие соединения.

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

Enter-PSSession 192.168.1.160 -Credential VMNAME\User

Значения 192.168.1.160 и VMNAME\User необходимо заменить адресом удаленного узла и именем пользователя Windows на сервере.

Теперь удаленный доступ через Powershell работает. Однако, есть еще один ньюанс. Возможно, кто-либо из вас пользуется профилями в Powershell. Профили – это специальные скрипты, которые запускаются при запуске самой консоли. Здесь, например, можно определить все необходимые алиасы и выполнить предварительные действия.

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

После этого, при подключении к удаленному узлу, при использовании коммандлета Enter-PSSession следует указать имя конфигурации.

Enter-PSSession 192.168.1.160 -ConfigurationName Config1 -Credential VMNAME\User

Теперь можно не тратить ресурсы сервера на создание сессии подключения через Remote Desktop Services и удаленно управлять сервером, используя Powershell.

blog.zwezdin.com

Windows PowerShell 2.0

Ro8

! , Windows PowerShell 2.0

, Windows Server 2008 R2 Enterprise ( Server Core), Windows 7 (x64) Ultimate

Windows Server 2008 R2 Windows PowerShell powershell

WinRM, get-service winrm. ,

Windows 7. C Scripts

Scripts Service_status.ps1

Service_status.ps1 ( ), , :

clear - PowerShell

get-service s* | sort-object status - , S Status

Windows 7 PowerShell

Windows Server 2008 R2

invoke-command -computername Server01 -credential exityrwed/Administrator -ScriptBlock {get-executionpolicy}, Server01 - ( Windows Server 2008 R2), exityrwed - , Windows Server 2008 R2

Administrator - ,

{get-executionpolicy} - , . PowerShell, get-executionpolicy

invoke-command -computername Server01 -credential exityrwed/Administrator -ScriptBlock {get-executionpolicy} , Windows Server 2008 R2 Unrestricted,

Service_status.ps1 Windows Server 2008 R2, invoke-command -filepath C:\Scripts\Service_status.ps1 -computername Server01, C:\Scripts\Service_status.ps1 - Service_status.ps1

Server01 - ,

, Service_status.ps1 Server01 S

, , stop-service sppsvc

sppsvc Server01

File-Save As

Scripts : Stop_service_sppsvc

Stop_service_sppsvc.ps1

Stop_service_sppsvc.ps1 Server01

invoke-command -filepath C:\Scripts\Stop_service_sppsvc.ps1 -computerName Server01

Stop_service_sppsvc.ps1 , PowerShell

Stop_service_sppsvc.ps1 sppsvc Server01 .

sppsvc Server01 Service_status.ps1

invoke-command -filepath C:\Scripts\Service_status.ps1 -computername Server01

, sppsvc Server01

remontcompa.ru

PowerShell Remoting — настройка и удаленное управление

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

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

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

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

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

get-item wsman:localhostClientTrustedHosts

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

set-item wsman:localhostclienttrustedhosts -value *

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

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

###################################################################################### # добавляет NewHost в список TrustedHost с фильтрацией если такая строка уже есть # можно дергать из командной строки указывая параметр напрямую например # .Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ( $NewHost = '192.168.2.89' ) Write-Host "adding host: $NewHost" $prev = (get-item WSMan:localhostClientTrustedHosts).value if ( ($prev.Contains( $NewHost )) -eq $false) { set-item WSMan:localhostClientTrustedHosts -Value "$prev, $NewHost" } Write-Host '' Write-Host 'Now TrustedHosts contains:' (get-item WSMan:localhostClientTrustedHosts).value

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

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

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

WinRM quickconfig

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

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

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

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

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

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

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

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

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

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

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

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

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

Invoke-Command

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

$sb = { команды для удаленной машины разделенные точкой с запятой }

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

Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb

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

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

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

$sb = [Scriptblock]::Create( $SomeString )

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

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

$DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03

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

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

Enter-PSSession -Session $DC01

если 1-to-many

Invoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50}

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

Get-PSSession | Remove-PSSession

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

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

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

Автор: pak-nikolai

Источник

www.pvsm.ru

PowerShell Remoting — настройка и удаленное управление

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

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

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

get-item wsman:\localhost\Client\TrustedHosts для разрешения подключаться ко всемset-item wsman:localhost\client\trustedhosts -value * Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

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

###################################################################################### # добавляет NewHost в список TrustedHost с фильтрацией если такая строка уже есть # можно дергать из командной строки указывая параметр напрямую например # .\Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ( $NewHost = '192.168.2.89' ) Write-Host "adding host: $NewHost" $prev = (get-item WSMan:\localhost\Client\TrustedHosts).value if ( ($prev.Contains( $NewHost )) -eq $false) { set-item WSMan:\localhost\Client\TrustedHosts -Value "$prev, $NewHost" } Write-Host '' Write-Host 'Now TrustedHosts contains:' (get-item WSMan:\localhost\Client\TrustedHosts).value он проверяет на есть ли такая запись, если нет то добавляет в список. Вызывать можно из командной строки указав адрес или имя.

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

WinRM quickconfig это не тоже самое что Enable-PSRemotingУдаленные подключения1. Сессии 1-to-1 открываются командойEnter-PSSession -ComputerName Test Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential, выход происходит командлетом Exit-PSSession

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

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

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

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

Invoke-Command определяем что будем исполнять так:$sb = { команды для удаленной машины разделенные точкой с запятой } передаем на удаленные машины Test1 и Test2Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

Запомним что на той стороне будет новый скоп, так что ваш скрипт не получит значений из вашей консоли, а переменные скрипта могут оказаться на той стороне пустыми. Поэтому передавайте сразу целиком готовые инструкции и скрипты с параметрами. для полноценного использования Invoke-Command надо уметь превращать строки в скрипт блоки. Например у вас есть команды которые зависят от какогото списка, вам нужно сгенерировать строку, превратить ее в ScriptBlock и отправить на удаленный комп:$sb = [Scriptblock]::Create( $SomeString ) kuda78В статье пропущен очень важный момент — передача параметров в скрипт на удаленной машине.

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

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

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

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

$DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03 использовать можно такие же параметры подключения как в Invoke-Command

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

Enter-PSSession -Session $DC01 если 1-to-manyInvoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50} посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession закрыть вообще все сессииGet-PSSession | Remove-PSSession прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

fetisovvs.blogspot.com