Powershell подключиться к другому компьютеру: PowerShell: используем Invoke-Command для запуска команд/скриптов на удаленных компьютерах

21.06.2020 alexxlab

Содержание

PowerShell: используем Invoke-Command для запуска команд/скриптов на удаленных компьютерах

В этой статье мы рассмотрим особенности использования командлета Invoke-Command для удаленного выполнения команд и скриптов. Возможно запускать команды удаленно на одном компьютере, или параллельно на множестве компьютерах в вашей сети. Командлет Invoke-Command использует возможности удаленного управления, заложенные в PowerShell Remoting. PowerShell Remoting позволяет удаленно подключаться к PowerShell сессиям на компьютерах через службу WinRM (Windows Remote Management) через протокол Web Services for Management (WS-Management). Этот сервис дает возможность принимать команды Powershell и устанавливать сеансы.

Настройка WinRM для PowerShell Remoting

Для связи между компьютерами в PowerShell Remoting используется протокол HTTP (порт TCP/5985) или HTTPS (порт TCP/5986). По умолчанию используется протокол HTTP, но даже этот трафик шифруется с помощью ключа AES-256 (впрочем, есть угроза атак man-in-the middle). Возможна аутентификация через Kerberos (в домене) или NTLM.

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

Get-Service -Name "*WinRM*" | fl

Если служба не запущена, запустите ее:

Enable-PSRemoting

WinRM has been updated to receive requests.WinRM service started.WinRM is already set up for remote management on this computer.

Данная команда запустит службу WinRM (установит автоматический запуск), выставит настройки winrm по-умолчанию и добавит исключение в Windows Firewall. Команда Enable-PSRemoting –Force включает WinRM без запроса пользователя.

Теперь к компьютеру можно подключиться удаленно через PowerShell Remoting.

Обратите внимание, что PowerShell Remoting по-умолчанию не работает, если тип вашей сети определен как общедоступная (Public). В этом случае команда вернет ошибку:

Set-WSManQuickConfig : ... WinRM firewall exception will not work since one of the network connection types on this machine is set to Public.  Change the network connection type to either Domain or Private and try again.

Вам нужно изменить тип сети на частную (private), или использовать команду:

Enable-PSRemoting –SkipNetworkProfileCheck.

Также нужно включить правило Window Defender Firewall, которое разрешает доступ к WinRM в общедоступных сетях. Вы можете включить правило брандмауэра с помощью GPO или PowerShell:

Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress Any

Чтобы проверить подключение к удаленному компьютер через PowerShell Remoting используется команда:

Test-WsMan compname1

Если у вас нет домена, или вы обращаетесь к компьютерам через PowerShell Remoting по IP адресам, в этом случае используется для аутентификации используется протокол NTLM. При использовании NTLM, при выполнении команду Invoke-Command появится ошибка:

[192.168.1.201] Connecting to remote server 192.168.1.201 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: thetransport 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. + FullyQualifiedErrorId : CannotUseIPAddress,PSSessionStateBroken

Для корректной работы NTLM аутентификации, на компьютере, с которого вы будете устанавливать подключения нужно выполнить дополнительные действия: выпустить SSL сертификат или добавить имя/IP адрес хоста в доверенные:

Set-Item wsman:\localhost\Client\TrustedHosts -value 192.168.1.201

Либо можно разрешить подключение ко все компьютерам (не рекомендуется, т.к. один из главных недостатков NTLM – он не осуществляет проверку подлинности).

Set-Item wsman:\localhost\Client\TrustedHosts -value *

Аналогичные настройки нужно сделать на удаленных хостах.

Чтобы вывести список доверенных хостов, выполните команду:

Get-Item WSMan:\localhost\Client\TrustedHosts

Чтобы применить изменения, перезапустите службу WinRM:

Restart-Service WinRM

Удаленное выполнение PowerShell с помощью Invoke-Command

Командлет Invoke-Command позволяет выполнить команду на одном или нескольких удаленных компьютерах.

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

Invoke-Command -ComputerName dc01 -ScriptBlock {$PSVersionTable.PSVersion}

Эта команда выведет в вашу консоль значение версии PowerShell, установленной на удаленном компьютере, имя которого указано в параметре -ComputerName. В блоке -ScriptBlock {[cmdlet]} указывается команда, которую нужно запусть на удаленном компьютере.

По-умолчанию команда, посланная через Invoke-Command выполняется на удалённом компьютере от текущего пользователя. Если нужно выполнить команду от имени другого пользователя, сначала нужно запросить учетные данные пользователя и сохранить их в переменную:

$cred = Get-Credential Invoke-Command -ComputerName comp-buh3 -Credential $cred -ScriptBlock {Get-NetAdapter}

Эта PowerShell команда выведет список сетевых интерфейсов на удаленном компьютере:

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

Invoke-Command -Computername dc01 -ScriptBlock {Get-TimeZone| select DisplayName;Set-TimeZone -Name "Astrakhan Standard Time”}

Invoke-Command позволяет выполнять не только отдельные команды, но и запускать скрипты PowerShell. Для этого используется аргумент -FilePath (вместо –ScriptBlock). При этом вы указываете путь к локальному PS1 файлу скрипта на вашем компьютере (вам не нужно копировать файл скрипт на удаленный компьютер):

Invoke-Command -ComputerName Server01 -FilePath c:\PS\Scripts\GetComputerInfo.ps1

Используем Invoke-Command для параллельного запуска команд на нескольких компьютерах

Командлет Invoke-Command можно использовать для параллельного выполнения команд на нескольких удаленных компьютерах.

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

Invoke-Command server1, server2, server3 -ScriptBlock {get-date}

Список компьютеров можно поместить в переменную (массив):

$servers = @(″server1″,″server2″,″server3″) Invoke-Command -ScriptBlock { get-date} -ComputerName $servers

Или получить из текстового файла:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName(Get-Content c:\ps\servers. txt)

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

Чтобы выполнить команду на всех Windows Server в домене, исопльзуйте такой код:

$computers = (Get-ADComputer -Filter 'operatingsystem -like "*Windows server*" -and enabled -eq "true"').Name Invoke-Command -ComputerName $computers -ScriptBlock {get-date} -ErrorAction SilentlyContinue

Если компьютер выключен, или недоступен, благодаря параметру SilentlyContinue скрипт не будет остановлен и продолжит выполнение на других компьютерах.

Чтобы понять с какого компьютера получены результаты, нужно использовать специальную переменную окружения PSComputerName.

$results = Invoke-Command server1, server2, server3 -ScriptBlock {get-date} $results | Select-Object PSComputerName, DateTime

При запуске команды через Invoke-Command на нескольких компьютерах она выполняется параллельно. В Invoke-Command есть ограничение на максимальное количество компьютеров, которыми можно управлять одновременно (ограничение на количество одновременных PSSession). Оно определяется параметром ThrottleLimit (по умолчанию 32). Если вам нужно выполнить команду одновременно более чем на 32 компьютерах (например, на 128), используйте параметр –ThrottleLimit 128 (но это вызывает повышенную нагрузку на ваш компьютер).

Для запуска команд на удаленных компьютерах через Invoke-Command в фоновом режиме используется специальный атрибут –AsJob. В этом случае результат выполнения команды не возвращается в консоль. Чтобы получить результаты нужно использовать командлет Receive-Job.

PowerShell. О удалённом подключении (about_Remote) — Клёвый код

С помощью PowerShell можно выполнить удаленные команды, как на одном компьютере, так и на нескольких компьютерах. Использовать как временное, так и постоянное подключение. Можно так же запустить интерактивный сеанс с одним удаленным компьютером.

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

Примечание: Для использования Windows PowerShell Remoting, локальные и удаленные компьютеры должны быть настроены на удаленное взаимодействие. Для получения дополнительной информации см about_Remote_Requirements.

Как начать интерактивный сеанс (ENTER-PSSESSION)

Самый простой способ выполнять удаленные команды — это начать интерактивный сеанс с удаленным компьютером.

Когда начинается сессия, команды которые вы вводите, выполняются на удаленном компьютере, как если бы вы набрали их непосредственно на удаленном компьютере. Вы можете подключиться только к одному компьютеру в каждом интерактивном сеансе.

Чтобы начать интерактивный сеанс, используйте командлет Enter-PSSession.

Следующая команда начинает интерактивный сеанс с компьютером Server01:

Командная строка изменяется, чтобы указать, что вы подключены к компьютеру Server01.

Теперь можно вводить команды на компьютере Server01.

Чтобы завершить интерактивный сеанс, надо ввести:

Для получения дополнительной информации см Enter-PSSession.

Как работать с командлетами, которые имеют параметр ComputerName для дистанционного получения данных

Некоторые командлеты имеют параметр ComputerName, он позволяет получать объекты с удаленных компьютеров.

Поскольку эти командлеты не используют WS-Management на базе Windows PowerShell Remoting, вы можете использовать параметр ComputerName этих командлетов на любом компьютере под управлением Windows PowerShell. Компьютеры могут быть не настроены для работы Windows PowerShell Remoting, и компьютеры могут не отвечать требованиям к системам для удаленного доступа.

Ниже приведён список командлетов имеющих параметр ComputerName:

Clear-EventLog
Get-Counter
Get-EventLog
Get-HotFix
Get-Process
Get-Service
Get-WinEvent
Get-WmiObject
Limit-EventLog
New-EventLog
Remove-EventLog
Restart-Computer
Stop-Computer
Show-EventLog
Test-Connection
Write-EventLog

Для примера, следующая команда получает службы на удаленном компьютере Server01:

Get-Service -ComputerName Server01

Обычно командлеты, поддерживающие удаленную работу без специальной настройки, имеют параметр ComputerName и не имеют параметра Session.

Чтобы отобразить эти командлеты надо выполнить следующую команду:

Get-Command | where { $_.Parameters.Keys -contains «ComputerName» -and $_.Parameters.Keys -NotContains «Session»}

Как запустить команды удалённо

Для запуска команд, не поддерживающих параметр ComputerName, на удаленных компьютерах. Можно использовать командлет Invoke-Command.

Для указания списка компьютеров или одного компьютера можно воспользоваться параметром ComputerName. Для задания одной или несколько команд надо воспользоваться парамертом ScriptBlock.

Например, следующая команда выполняет команду Get-Culture на компьютере Server01.

Invoke-Command -ComputerName Server01 -scriptblock {Get-Culture}

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

Чтобы установить постоянное подключение к удаленному компьютеру, надо использовать параметр Session.

Как создать постоянное соединение (PSsession)

При использовании параметра ComputerName и командлета Invoke-Command, оболочка Windows PowerShell устанавливает подключение только для данной команды. Затем, когда команда завершена, оболочка закрывает соединение. Любые переменные или функции, которые были определены в команде, будут потеряны.

Чтобы создать постоянное подключение к удаленному компьютеру, надо воспользоваться командлетом New-PSSession. Например, следующая команда создает сеансы PSSession на компьютерах Server01 и Server02, а затем сохраняет эти сеансы в переменной $s.

$s = New-PSSession -ComputerName Server01, Server02

Как выполнять команд в PSsession

Воспользовавшись PSSession, можно запустить серию удаленных команд, которые будут иметь одно общее окружение. И соответственно иметь общий доступ к таким данным, как функции, псевдонимы и значения переменных. Для запуска команды в PSSession, используется параметр Session в командлете Invoke-Command.

Например, следующая команда использует командлет Invoke-Command для выполнения командлета Get-Process в сеансах PSSession $s на компьютерах Server01 и Server02. Команда сохраняет процессы в переменной $р в каждом из сеансов PSSession.

Invoke-Command -Session $s -ScriptBlock {$p = Get-Process}

Так как PSSession использует постоянное подключение, вы можете запустить другую команду в той же сессии PSSession, в которой уже задана переменная $р. Следующая команда подсчитывает количество процессов, сохраненных в переменной $р.

Invoke-Command -Session $s -ScriptBlock {$p. count}

Invoke-Command -Session $s -ScriptBlock {$p.count}

Как запустить удалённые команды на нескольких компьютерах

Для запуска удаленной команды на нескольких компьютерах, необходимо ввести все имена компьютеров в значении параметра ComputerName командлета Invoke-Command. Разделите имена компьютеров запятыми.

Например, следующая команда запускает команду Get-Culture на трех компьютерах:

Invoke-Command -ComputerName S1, S2, S3 -ScriptBlock {Get-Culture}

Можно так же запустить команду в нескольких сеансах PSSession. Следующие команды создают сеансы PSSession на компьютерах Server01, Server02, Server03 и затем выполняется команда Get-Culture в каждом из сеансов.

$s = New-PSSession -ComputerName Server01, Server02, Server03 Invoke-Command -Session $s -ScriptBlock {Get-Culture}

$s = New-PSSession -ComputerName Server01, Server02, Server03

Invoke-Command -Session $s -ScriptBlock {Get-Culture}

Чтобы указать в списке компьютеров локальный компьютер надо ввести имя локального компьютера, точку (.) или localhost.

Invoke-Command -ComputerName S1, S2, S3, localhost -ScriptBlock {Get-Culture}

Как запустить скрипт на удаленных компьютерах

Чтобы запустить скрипт с локального компьютера, на удаленных компьютерах, надо использовать параметр FilePath командлета Invoke-Command.
Например, следующая команда запускает сценарий sample.ps1 на компьютерах S1 и S2:

Invoke-Command -ComputerName S1, S2 -FilePath C:\Test\Sample.ps1

Результат работы скрипта отображается на локальном компьютере. Для выполнения данного скрипта нет необходимости распространять файлы скрипта.

Как остановить удалённые команды

Чтобы прервать команду, надо нажать «CTRL» + «C». Запрос прерывания передастся на удаленный компьютер и завершит работу удаленного управления.

Удаленное управление компьютерами, не входящими в домен — sergey vasin

Мы знаем, что удаленное подключение к компьютерам домена посредством PowerShell происходит практически прозрачно. Все, что нам нужно сделать, это, к примеру:

Enter-PSSession -ComputerName computer_name

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

Однако, если мы попытаемся подключиться к компьютеру рабочей группы (для начала по IP-адресу), мы увидим что-то вроде:

New-PSSession : [10.0.0.5] Connecting to remote server 10.0.0.5 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.

Что нам тут сообщают, так это то, что подключиться мы можем только в том случае, если будем использовать https или добавим IP-адрес компьютера к списку TrustedHosts, а также явным образом указав учетные данные для подключения.

Для чего это нужно.

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

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

Мы можем использовать HTTPS в качестве транспорта и в этом случае удаленному компьютеру придется предъявлять нам сертификат, который мы и будем проверять. При этом наш компьютер должен доверять центру сертификации, выдавшему этот сертификат.

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

HTTPS

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

Certificate

Для начала нужно установить сертификат, которому бы доверял компьютер, с которого мы будем подключаться. Если компьютер, с которого мы хотим подключиться является членом домена и в домене развернута роль Certificate Services, то можно выдать сертификат компьютеру рабочей группы через службы сертификатов. В этом случае вопрос доверия выдвнному сертификату не возникнет. Или же можно создать самоподписанный сертификат с использованием какой-либо утилиты для создания сертификатов (например, makecert) или командлета New-SelfSignedCertificate.

Так как мы планируем использовать этот сертификат для подключения к компьютеру и по полному имени (computer_name.domain_name.com), по имени компьютера без упомининия домена (computer_name) и по ip-адресу, сразу же создадим сертификат, который бы удовлетворял всем этим условиям.

Сразу же оговоримся. Для того, чтобы подключаться к компьютеру по полному имени — (FQDN — Fully Qualified Domain Name) его вовсе не обязательно вводить в домен. Мы можем, к примеру, создать для этого комьютера запись в нашей внутренней системе DNS в зоне domain_name.com и это позволит нам использовать имя computer_name.domain_name.com для обращения к этому компьютеру, хотя он по-прежнему остается членом рабочей группы.

Итак, создаем сертификат:

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=computer_name.domain_name.com" -KeyUsage DigitalSignature, KeyEncipherment -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1","2.5.29.17={text}DNS=computer_name.domain_name.com&DNS=computer_name&IPAddress=10.0.0.5")

Что мы тут сделали.

При помощи параметра -CertStoreLocation мы указали где нужно сохранить сертификат, а именно — в локальном хранилище компьютера.

Параметр -Subject указывает значение поля «Subject» («Субъект») создаваемого сертификата, и это то самое значение, на которое, среди всех прочих, будет обращать внимание командлет Enter-PSSession (или New-PSSession), когда будет пытаться установить подключение к компьютеру. Строго говоря, имя компьютера, указываемое в качестве значения -ComputerName командлета Enter-PSSession должно совпадать со значением поля Subject сертификата, установленного на компьютере, к которому мы подключаемся.

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

Параметр -KeyUsage задает способы использования ключа, в нашем случае — DigitalSignature, KeyEncipherment (Цифровая подпись, Шифрование ключей). Стоит сказать, что это соответствует значению по умолчанию, так что этот параметр мы вполне могли и не указывать.

В параметре -TextExtension мы указываем значения для нескольких полей сертификата.

OID 2.5.29.37 задает Enhanced Key Usage. Два указанных нами значения — 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1 — задают Client Authentication и Server Authentication, соответственно.

OID 2. 5.29.17 — Subject Alternative Name — позволяет нам расширить список значений, используя которые мы сможем обратиться к компьютеру.

В отсутствие Subject Alternative Name, единстенным именем, по котому мы могли бы обратиться к компьютеру было бы имя, заданное в поле Subject.

Данное же поле позволяет нам задать еще несколько значений, принадлежащих к одному из поддерживаемых типов — DirectoryName, DNS, Email, IPAddress, RegisteredID, UPN, URL.

Как видно из примера, мы использовали DNS и IPAddress. Причем никто не будет против, если имя, указанное в поле Subject мы укажем и здесь тоже.

В случае успешного завершения работы командлета будет выведено два значения: Thumbprint и Subject. Значение отпечатка (Thumbprint) нам понадобится на следующем шаге.

Listener

Теперь нам нужно создать прослушиватель (listener) для транспорта HTTPS и указать созданный нами сертификат для использования этим прослушивателем.

Вообще, мы предполагаем, что PowerShell Remoting уже включен, но если же вдруг это не так, мы можем его включить при помощи командлета:

Enable-PSRemoting

Если же вступать в диалог с командлетом Enable-PSRemoting и отвечать на задаваемые вопросы не хочется, можно запустить его с параметром -Force.

Enable-PSRemoting -Force

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

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

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

Итак, возвращаемся к созданию прослушивателя. Создавать мы его будем при помощи утилиты winrm. Одним из аргументов будет значение отпечатка того сертификата, который бы мы хотели использовать для удаленных подключений к этому компьютеру.

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

Get-ChildItem -Path Cert:\LocalMachine\My

Теперь создадим прослушиватель:

winrm create winrm/config/listener?Address=*+Transport=HTTPS @{Hostname="computer_name.domain_name.com";CertificateThumbprint="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

где вместо сорока букв ‘X’ мы указываем обпечаток (thumbprint) нужного нам сертификата.

Если мы запускаем эту команду в консоли PowerShell, мы можем получить что-то вроде:

Invalid use of command line. Type "winrm -?" for help.

Происходит это потому, что синтаксис утилиты winrm рассчитан на обычную командную строку и он не учитывает, что у PowerShell может быть свое мнение на использование разных специальных символов.

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

--%

Например, так:

winrm --% create winrm/config/listener?Address=*+Transport=HTTPS @{Hostname="computer_name.domain_name.com";CertificateThumbprint="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}

Firewall

Далее нам нужно создать правило для сетевого экрана. Это можно сделать как через Microsoft Management Console — wf.msc, так и через PowerShell:

New-NetFirewallRule -DisplayName 5986 -Protocol TCP -LocalPort 5986

Trust Issues

Как мы помним, для того, чтобы доменный компьютер мог подключиться к компьютеру рабочей группы, он должен доверять сертификату (или его издателю), который будет предъявлен компьютером к которому мы подключаемся.

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

Enter-PSSession : Connecting to remote server workstation failed with the following error message : 
The server certificate on the destination computer (computer_name:5986) has the following errors:
The SSL certificate is signed by an unknown certificate authority.  
For more information, see the about_Remote_Troubleshooting Help topic.

Для того, чтобы доменный компьютер начал с большей степенью доверия относиться к созданному нами сертификату, его потребуется экспортировать из хранилища сертификатов Personal компьютера рабочей группы и импортировать в хранилище Trusted Root Certification Authorities доменного компьютера.

Экспортировать сертификат можно как при помощи Microsoft Management Console (она же mmc), так и посредством PowerShell. Так как закрытый ключ в данном случае нам не нужен, мы воспользуемся командлетом Export-Certificate.

$cert = Get-ChildItem -Path Cert:\LocalMachine\My\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Export-Certificate -Cert $cert -Type CERT -FilePath c:\cert.cer

Теперь нам нужно скопировать полученный файл на доменный компьютер (предположим, что мы скопировали его в то же место, корень диска C:) и импортировать находящийся в нем сертификат в хранилище Trusted Root Certification Authorities.

Опять же, это можно сделать как через mmc (уже на доменном компьютере), так и через PowerShell:

Import-Certificate -FilePath C:\cert.cer -CertStoreLocation Cert:\LocalMachine\Root\

Enter-PSSession

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

$cred = Get-Credential -Credential username

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

Enter-PSSession -ComputerName 10.0.0.5 -UseSSL -Credential $cred

Так как мы собираемся подключаться к удаленному компьютеру как через IP-адрес, так и используя имя компьютера (computer_name и computer_name.domain_name.com), давайте добавим для него запись в DNS. И хотя в отсутствие записи в DNS нам могут помочь NetBios и LLMNR, тем не менее наличие записи в DNS будет более правильным вариантом.

Сделать это можно через Microsoft Management Console — DNS Manager, или же через PowerShell:

Add-DnsServerResourceRecordA -Name computer_name -IPv4Address 10. 0.0.5 -ZoneName domain_name.com

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

Enter-PSSession -ComputerName computer_name -UseSSL -Credential $cred

так и полное:

Enter-PSSession -ComputerName computer_name.domain_name.com -UseSSL -Credential $cred

TrustedHosts

Теперь рассмотрим второй вариант, который заключается в том, что вы добавляете имена и IP-адреса всех компьютеров рабочих групп, к которым вы будете подключаться, в TrustedHosts. Результатом этого действия станет то, что ваш компьютер будет относиться к ним с определенной долей доверия и не будет пытаться проверить их подлинность.

Получить текущее значение TrustedHosts можно так:

Get-ChildItem WSMan:\localhost\Client\TrustedHosts

По умолчанию какое-либо содержимое отсутствует, но если вы ранее что-то уже задавали, то новые значения нужно будет добавить к уже существующим. Опять же, так как мы хотим иметь возможность подключиться с использованием различной идентификационной информации (IP-адрес, имя, FQDN), в TrustedHosts мы добавим все три значения.

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "computer_name,computer_name.domain_name.com,10.0.0.5"

После этого нам потребуется подтвердить понимание того факта, что изменение значения TrustedHosts приведет к тому, что подлинность указанных компьютеров проверяться не будет, введя ‘Y’.

Если мы не хотим, чтобы после введения вышеприведенной команды нам приходилось подтверждать свое действие, мы можем добавить к ней параметр -Force:

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "computer_name,computer_name.domain_name.com,10.0.0.5" -Force

Теперь мы можем подключиться к удаленному компьютеру используя прослушиватель (listener) по умолчанию. Для этого мы используем те же самые команды, за исключением параметра -UseSSL:

Enter-PSSession -ComputerName 10.0.0.5 -Credential $cred

Enter-PSSession -ComputerName computer_name -Credential $cred

Enter-PSSession -ComputerName computer_name. domain_name.com -Credential $cred

Server Manager

Следствием добавления имен компьютера в TrustedHosts явлется еще одна полезная вещь. Теперь мы можем управлять им из Server Manager. А возможно это потому, что для удаленного управления системами Server Manager использует именно WinRM — тот же самый механизм, что используется и для удаленного подключения из через PowerShell.

Стоит сказать, что управлять рабочими станциями через Server Manager у нас не получится, но для серверов, по тем или иным причинам не входящим в домен, это вполне себе полезная возможность.

Для добавления компьютера к консоли Server Manager в левом меню выберем «All Servers», нажмем на «All Servers» правой кнопкой мыши и выберем «Add Servers». В открывшемся окне перейдем на вкладку DNS, введем имя нашего сервера и нажмем на кнопку поиска. Если мы не забыли добавить запись о нем в DNS, он будет найден. Далее мы выделим его и нажмем на треугольник справа, чтобы добавить его к списку серверов, которыми мы будем управлять из Server Manager. Нажимаем на кнопку OK. Теперь наш новый сервер должен отобразиться в списке SERVERS.

Скорее всего напротив его имени будет находиться сообщение об ошибке — Kerberos target resolution error. Нажимаем на имя сервера правой кнопкой мыши и выбираем «Manage As …». Вводим данные учетной записи администратора удаленного компьютера (имя пользователя должно быть в формате computer_name\user_name) и нажимаем OK.

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

Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell

PowerShell удаленное подключение к компьютеру рабочей группы

Я пытаюсь удалить powershell из моего домена, присоединенного к PC, на сервер в нашем DMZ, но не могу понять, как заставить его работать.

Сервер DMZ имеет прослушиватель, настроенный для HTTP на порту 5985 по умолчанию, который включен. Два NIC в машине оба помечены для общедоступных сетей, поэтому я изменил правило брандмауэра Windows Remote Management (HTTP-In) для общедоступного профиля, чтобы принимать соединения от моего IP, а также от локальной подсети, которая уже была настроена.

На моей клиентской машине (Windows 10) я добавил имя хоста сервера к WSMan:\localhost\Client\TrustedHosts и добавил LocalAccountTokenFilterPolicy (значение: 1, Тип: DWORD) в реестр.

Я создаю объект учетных данных с моими локальными учетными данными для сервера (servername\username), а затем пытаюсь $Sess = New-PSSession -ComputerName DMZCOMPUTER -Port 5985 -Credential $Cred соединение всегда пытается использовать Kerberos для подключения к машине, которая, очевидно, не будет работать.

Если я попробую $Sess = New-PSSession -ComputerName DMZCOMPUTER -Port 5985 -Credential $Cred -Authentication Basic , то получу сообщение об ошибке, что незашифрованный трафик в данный момент отключен. Другие схемы аутентификации выдают различные сообщения об ошибках,но я никогда не был в состоянии удаленно.

Может быть, я где-то упустил конфигурацию? Какие настройки необходимы (сервер & клиент) для использования удаленного powershell подключения к серверу рабочей группы из клиента, присоединенного к домену.

powershell powershell-remoting
Поделиться Источник Martin 25 октября 2016 в 19:43
2 ответа

10

В конце концов я понял это, было несколько проблем с тем, что я делал. Сначала ссылка на https://blogs.msdn.microsoft.com/wmi/2009/07/24/powershell-remoting-between-two-workgroup-machines/ имеет некоторую неверную информацию. В нем говорится, что запись реестра LocalAccountTokenFilterPolicy должна быть на клиентской машине, это неверно, она должна быть на серверной машине.
Другое исправление состояло в том, что я был тупицей, используя FQDN сервера в значении TrustedHosts, а затем используя только имя хоста при попытке создать сеанс.
Если кто-то еще пытается заставить это работать, то необходимо выполнить следующие шаги:
Запустите Enable-PSRemoting на серверной машине
Это запустит службу WinRM и установит ее автоматический запуск
Это позволит создать прослушиватель HTTP
Вы можете проверить это, запустив winrm enumerate winrm/config/listener
Это позволит включить правила брандмауэра удаленного управления Windows
Он создаст и настроит раздел реестра LocalAccountTokenFilterPolicy
Он сбросит разрешения на четырех хостах сеансов
Вы можете проверить это, запустив Get-PSSessionConfiguration
Запустите службу WinRM на клиентском компьютере
Выполнить Set-Item WSMan:\localhost\Client\TrustedHosts -Value <hostname or FQDN or server>
Вы можете добавить -Concatenate в конец Set-Item , если пытаетесь добавить сервер в список
Run $Cred = Get-Credential я только что ввел имя пользователя и пароль (а не servername\username) , как предложил кевмар
Выполните команду типа $S = New-PSSession -ComputerName <same name exactly that you put in the TrustedHosts> -Credential $Cred
Если все работает правильно команда должна просто вернуться
Если вы получаете сообщение об ошибке, в котором упоминается Kerberos, убедитесь, что вы используете одно и то же имя в параметре ComputerName и TrustedHosts
Если вы получаете сообщение об ошибке отказано в доступе, убедитесь, что LocalAccountTokenFilterPolicy настроен на сервере
Поделиться Martin 26 октября 2016 в 15:51

1

Сначала попробуйте создать объект учетных данных только с вашим именем пользователя и паролем. Пропустите попытку указать имя домена или сервера в учетных данных.
Затем попробуйте подключиться с адресом IP вместо имени компьютера. Вам все равно нужно будет добавить его в значения доверенных хостов.
Последнее, что нужно использовать, — это Test-WSMan для устранения неполадок вашей проблемы. Сообщение об ошибке должно дать вам четкий намек на то, в чем заключается проблема.
Поделиться kevmar 26 октября 2016 в 04:56
Похожие вопросы:

Удаленное подключение к mysql?
Я не использую php или mysql, но я пытаюсь обновить плату phpbb, которую я получил, но установщик one click забыл установить некоторые вещи в базу данных, поэтому я не могу перейти на новую версию,…

Удаленное подключение к базе данных clearDB heroku
Как я могу выполнить удаленное подключение к базе данных ClearDB MySQL на heroku, используя, например, браузер запросов MySQL. Где взять url, порт, логин и пароль?

SQL Server 2000-Удаленное Подключение ODBC
У меня четыре машины: XP с SQL 2000 (машина а, с которой у меня возникли проблемы) firewall:off port:1433 XP с SQL 2000 (машина B) firewall:off port:1433 XP (машина C) XP (Машина D) Примечание: Все…

Доступ к Azure Cloud экземплярам службы PaaS через PowerShell удаленное взаимодействие
У меня Azure веб-роль с 2 экземплярами (NB в PaaS роли, *not Azure виртуальных машин ). я могу подключиться к ним через удаленный рабочий стол, но я не знаю как это сделать удаленное взаимодействие…

Powershell удаленное взаимодействие: несогласованное подключение
Как получается, что одна команда Powershell работает на удаленной машине, но не другая с той же консоли? PS C:> Get-Service-Name WinRM -ComputerName win8 Название Статуса DisplayName —— —-…

Удаленное подключение jhipster к postgres
Я пытаюсь настроить jhipster для работы с базой данных postgres heroku. Вот мои параметры базы данных с отредактированными учетными данными: spring: profiles: dev datasource: dataSourceClassName:…

Android jellybean usb подключение к компьютеру не допускается
Я только что купил новый планшет lenovo A3500 (A7-50) с системой 4.2.2 jellybean system .my компьютер работает на widows 8. когда я подключаю свой планшет через кабель usb, компьютер не чувствует…

Как найти мой правильный Ip-адрес для удаленного подключения к другому компьютеру
Мой друг хотел подключиться к моему компьютеру с помощью подключения к удаленному рабочему столу. Но проблема в том, что я не знаю, что такое мой Ip-адрес. Мой компьютер подключен к интернету через…

RemoteApps на сервере 2012 и выше в среде рабочей группы
Я смог настроить RemoteApps на сервере 2008 R2 на AWS в среде рабочей группы. Я хочу сделать то же самое на сервере 2012 и выше. Я понимаю, что Microsoft удалила RemoteApp manager, когда сервер 2012. ..

Вперед удаленный запрос на подключение к компьютеру назначения (необязательно с использованием фреймворка бережливость )
Мы проводим технико-экономическое обоснование следующего требования: переадресуйте запрос на удаленное подключение на другой компьютер (необязательно с использованием Thrift framework). например,…
Дистанционное взаимодействие в среде PowerShell 2.0 | Windows IT Pro/RE
Разработка оболочки PowerShell 1.0 стала настоящим прорывом в развитии средств управления и автоматизации Windows XP, а также более поздних версий платформы ОС Windows. Базирующаяся на платформе. NET Framework технология PowerShell 1.0 включает в себя единообразную структуру команд (cmdlets), она наделена мощными встроенными средствами форматирования выходных данных и обеспечивает значительное повышение доступности других технологий, и прежде всего — инструментария управления Windows (WMI). Однако, хотя некоторые составные команды PowerShell 1.0 и объекты. NET могут подключаться к удаленным компьютерам, эта функция реализуется дифференцированно, в зависимости от конкретного случая. Команды, поддерживающие удаленные соединения, имеют параметр -ComputerName; кроме того, при установлении соединений они используют либо вызовы удаленных процедур (RPC), либо модель DCOM.
Во многих ситуациях RPC и DCOM хорошо справляются с задачами управления, однако при выполнении процедур диагностики и при выявлении причин неполадок порой возникают проблемы. К примеру, команда Get-Service может считывать данные служб с удаленного компьютера с помощью параметра -ComputerName, однако эта команда не имеет параметра -Credential, и потому для ее выполнения следует зарегистрироваться с учетной записью, имеющей разрешение на доступ к удаленной системе.
Но уже в версии Windows PowerShell 2.0 реализован альтернативный механизм подключения к удаленным компьютерам, именуемый remoting (удаленное взаимодействие). Этот механизм использует средства службы дистанционного управления Windows (Windows Remote Management, WinRM). Он обеспечивает подключение к удаленному компьютеру, а также запуск команд, выполняемых на этом удаленном компьютере. Поясню сказанное на примере. Средства подключения к удаленному рабочему столу относятся к графическому интерфейсу пользователя так же, как удаленное взаимодействие к командной строке оболочки PowerShell. Когда вы запускаете составную команду с использованием механизма удаленного взаимодействия, команда фактически выполняется на удаленном компьютере, но полученные результаты вы можете видеть на локальной машине.
Где можно получить Windows PowerShell 2.0
Оболочка PowerShell 2.0 и служба WinRM входят в состав систем Windows 7 и Windows Server 2008 R2, так что, если вы используете эти операционные системы, нет необходимости устанавливать данные компоненты. Если же вы работаете с системами Windows Vista SP2, Windows XP SP3, Windows Server 2008 SP2 или Windows Server 2003 SP2, вам придется загрузить и установить пакет Windows Management Framework Core (support. microsoft.com/kb/968930).
Включение функции удаленного взаимодействия
Для того чтобы компьютер мог устанавливать соединения с удаленными системами, на которых установлена оболочка PowerShell, необходимо обеспечить следующие условия.
Должна быть активирована служба WinRM.
Должен быть установлен прослушиватель WinRM, который принимает соединения с одного или нескольких IP-адресов.
Сетевой экран Windows должен быть сконфигурирован таким образом, чтобы появилась возможность установления соединений через WinRM.
Должен быть включен и надлежащим образом сконфигурирован сеанс PowerShell.
Если компьютер не будет принимать соединения от оболочек PowerShell, установленных на удаленных компьютерах, выполнение указанных условий необязательно.
Чтобы пользователи могли как можно скорее приступить к работе, разработчики Microsoft PowerShell создали команду Enable-PSRemoting, обеспечивающую автоматическую настройку упомянутых компонентов. Эту настройку нужно выполнять не на машине, с которой вы будете осуществлять удаленное взаимодействие, а на компьютере, к которому вы будете обращаться дистанционно. Выполнять команду Enable-PSRemoting можно лишь в в том случае, если вы работаете с оболочкой PowerShell с правами администратора. Если вы работаете с машинами Windows Vista, Server 2008 и более поздних версий, правой кнопкой мыши щелкните на значке PowerShell и в раскрывшемся меню выберите пункт Run as administrator. Если вы запустите команду Enable-PSRemoting с параметром -Force, при ее выполнении система не будет обращаться к вам за разрешением на выполнение каждого этапа конфигурации. Чтобы получить более подробные сведения о составной команде Enable-PSRemoting, выполните команду
Get-Help Enable-PSRemoting
Выполнение одной команды на удаленном компьютере
Самый простой способ подключиться к среде PowerShell на удаленном компьютере — воспользоваться командой Enter-PSSession. По умолчанию эта команда выполняется с параметром -ComputerName, поэтому при ее вводе с клавиатуры данный параметр можно не указывать. К примеру, для установления соединения с удаленным компьютером с именем rigel надо ввести с клавиатуры
PS C:\> Enter-PSSession rigel
Обратите внимание: для полноты картины я включаю в текст приглашение. Вам же не нужно вводить приглашение как часть команды.
После того как вы введете дистанционный сеанс, синтаксис приглашения PowerShell изменится. Теперь оно будет включать в себя заключенное в квадратные скобки имя удаленного компьютера; это будет означать, что вы установили соединение с удаленным компьютером. В данном случае приглашение будет выглядеть так:
[rigel]: PS C:\>
После установления дистанционного подключения все команды, введенные вами в командной строке, будут выполняться на удаленной машине. Так, если вы введете команду
[rigel]: PS C:\> Get-ChildItem C:\
команда Get-ChildItem будет выполнена на удаленной машине. Ее выходные данные будут содержать имена файлов и папок, хранимых в накопителе C удаленного компьютера. Чтобы завершить сеанс удаленного взаимодействия, воспользуйтесь командой Exit-PSSession
[rigel]: PS C:\> Exit-PSSession
Выполнение блока сценария (Scriptblock) на удаленном компьютере
Удаленное взаимодействие с помощью PowerShell позволяет выполнять на удаленном компьютере блок сценария, или scriptblock (то есть блок кода PowerShell, заключенный в фигурные скобки). Для этого нужно воспользоваться командой Invoke-Command с параметром -ComputerName. К примеру, в команде, отображенной на экране 1, я использовал команду Invoke-Command, с тем чтобы выполнить Get-ChildItem на удаленном компьютере. Просматривая экран 1, обратите внимание на то, что для установления соединения с удаленным компьютером перед тем, как запустить блок сценария, я не использовал команду Enter-PSSession. Команды Enter-PSSession и Invoke-Command — это два различных метода удаленного взаимодействия.

Экран 1. Выполнение блока сценария на удаленном компьютере
Первым параметром команды Invoke-Command является параметр -ScriptBlock; он указывает на код, который вы собираетесь выполнить. На экране 1 я опустил имя параметра -ScriptBlock, поскольку указывать его необязательно. Параметр -ComputerName содержит имя удаленного компьютера. Как можно увидеть в выходных данных команды Get-ChildItem, среда PowerShell для удобства оператора даже указывает имя удаленного компьютера в столбце PSComputerName выходных данных.
Выполнение блока сценария на нескольких удаленных компьютерах
Блок сценария можно выполнять и на нескольких удаленных компьютерах. Это называется конфигурацией «один ко многим» или веерным развертыванием. На экране 1 параметр -ComputerName команды Invoke-Command содержит одно имя, однако в него можно включать и несколько имен компьютеров. Так, команда
PS C:\> Invoke-Command {Get-ChildItem env: co*} -Computer titan, rigel
обеспечивает выполнение команды Get-ChildItem на двух удаленных компьютерах. В тексте статьи данная команда разбита на несколько строк, однако в консоли PowerShell ее следует вводить одной строкой. То же касается и других команд, разделенных на несколько строк. Так же, как и на экране 1, столбец PSComputerName в выходных данных будет содержать имена компьютеров.
Выполнение блока сценария в фоновом режиме
Среда PowerShell 2.0 дает возможность выполнять фоновые задания, то есть оператор может запускать команду в фоновом режиме. Такая возможность полезна при запуске команд, выполнение которых требует много времени.
Чтобы запустить фоновое задание на локальном компьютере, можно воспользоваться командой Start-Job. Но надо сказать, что данная команда не имеет параметра -ComputerName, а это значит, что ее нельзя использовать для выполнения фонового задания на удаленной машине. Вместо этого вам нужно будет выполнить команду Invoke-Command с параметром -AsJob. Так, верхняя команда на экране 2 инициирует выполнение блока сценария в виде фонового задания на удаленном компьютере titan. После того как я ввел эту команду, на экране сразу же появилось приглашение: оболочка PowerShell отправила блок сценария для выполнения на удаленный компьютер и после этого вернула мне управление. В предупреждении говорится, что выполненная команда не уместилась в окне консоли и потому не была включена в выходные данные. Если бы окно консоли у меня было шире, средство форматирования оболочки PowerShell включило бы команду в перечень выходных данных. В столбцах Id и Name указывается задание (его идентификатор и понятное имя соответственно), а в столбце State указывается, в каком состоянии находится задание: выполняется, приостановлено или завершено. В столбце HasMoreData содержится информация, свидетельствующая о том, что извлечены все данные, касающиеся того или иного задания, или что задание содержит больший объем сведений, которые следует извлечь.

Экран 2. Выполнение блока сценария в фоновом режиме на удаленном компьютере
Чтобы установить, завершено ли выполнение фонового задания, вы можете выполнить команду Get-Job, как показывает вторая команда на экране 2. Если при этом вы не используете каких-либо параметров, Get-Job проверяет состояние всех заданий, запущенных в ходе текущего сеанса. Если у вас выполняется несколько заданий одновременно, можете использовать такие параметры, как -Id или -Name, для указания на то, какое именно задание вы хотите проверить. Когда выполнение фонового задания завершится, столбец State выходных данных будет иметь значение Completed.
Для считывания результатов выполнения фонового задания можно использовать команду Receive-Job. Эта команда, как и команда Get-Job, возвращает выходные данные всех заданий, запущенных в ходе текущего сеанса, если вы не использовали параметр для указания на то, какое именно задание вас интересует. Так, последняя команда на экране 2 включает в себя параметр -Id, который указывает на то, что необходимо получить выходные данные о задании с идентификатором 9. Я опустил имя параметра -Id, поскольку его указывать необязательно. На экране 3 отображены последние строки выходных данных, касающихся выполнения рассматриваемого дистанционного фонового задания.

Экран 3. Образец результатов выполнения фонового задания на удаленном компьютере
Создание сеансов PowerShell
Приведенные выше примеры показывают, как получить доступ к приглашению PowerShell на удаленной машине и как выполнять команды на удаленных компьютерах. Но я пока не упоминал о том, что удаленное взаимодействие всегда осуществляется в контексте сеанса. Сеанс — это, скажем так, место обитания PowerShell. Когда вы открываете окно консоли PowerShell или окно интегрированной среды сценариев (ISE) PowerShell, вы создаете сеанс. Без использования средств удаленного взаимодействия все сеансы выполняются на локальном компьютере и не зависят друг от друга. Во всех приведенных выше примерах удаленного взаимодействия создаются временные сеансы, которые автоматически прекращаются по завершении удаленного взаимодействия. Кроме того, существует возможность создавать экземпляры сеансов удаленного взаимодействия и повторно использовать их. Такой подход гораздо эффективнее в случаях, когда необходимо обращаться к удаленным компьютерам более одного раза.
Для создания новых сеансов используется команда New-PSSession с параметром -ComputerName. Имя этого параметра в командах можно опускать. Так, команда
C:\> $sessions = New-PSSession phineas, ferb, perry
создает три сеанса на трех компьютерах с именами phineas, ferb и perry. Вы можете просмотреть эти сеансы, создав переменную $sessions. Для этого в командной строке нужно ввести имя
$sessions
и нажать клавишу ввода. Параметр -Session команды Invoke-Command поддерживает объекты session, созданные с помощью команды New-PSSession, поэтому далее вы можете использовать команду, подобную следующей:
C:\> Invoke-Command {Get-ChildItem} -session $sessions
Эта команда выполняет команду Get-ChildItem на машинах phineas, ferb и perry, но не разрывает соединения. Вы можете добавить параметр -AsJob и выполнить команду в фоновом режиме:
C:\> Invoke-Command {Get-ChildItem} -session $sessions -asjob
Далее можно использовать команды Get-Job и Receive-Job для проверки состояния задания и получения его результатов.
Новый подход к работе
Удаленное взаимодействие с помощью средств PowerShell — это новый мощный механизм выполнения команд на удаленных компьютерах. Надеюсь, эта статья подвигнет вас на исследование новых возможностей. Более подробные сведения об удаленном взаимодействии, включая проблемы диагностики, можно найти в справочных темах PowerShell about_Remote по адресу technet.microsoft.com/en-us/library/dd347616.aspx.
Билл Стюарт ([email protected]) — системный и сетевой администратор компании French Mortuary, Нью-Мехико
Дистанционное взаимодействие в среде PowerShell 2.0
Поделитесь материалом с коллегами и друзьями
Удаленное управление 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:\>

Удаленное управление при помощи диспетчера сервера
В ОС Windows Server® 2008 R2 при помощи Диспетчер серверов можно выполнять ряд задач управления на удаленных компьютерах. Для удаленного управления компьютером при помощи Диспетчер серверов необходимо подключить Диспетчер серверов к удаленному компьютеру так же, как подключаются консоли управления (ММС) при использовании других технологий.
Перечисленные ниже сценарии удаленного управления поддерживаются из Диспетчер серверов в ОС Windows Server 2008 R2.
Сервер-сервер   Диспетчер серверов при полной установке Windows Server 2008 R2 можно использовать для управления ролями и компонентами, установленными на другом сервере под управлением Windows Server 2008 R2.

Сервер-Server Core (ядро сервера)   Диспетчер серверов при полной установке Windows Server 2008 R2 можно использовать для управления ролями и компонентами, установленными на компьютере под управлением Windows Server 2008 R2 в установке Server Core.

Клиент-сервер   Диспетчер серверов установлен в составе Средства администрирования удаленного сервера на компьютере под управлением Windows® 7. Этот сценарий можно использовать для управления ролями и компонентами на компьютере, работающем под управлением Windows Server 2008 R2 — либо в полной установке, либо в установке Server Core.

Исходный компьютер -удаленный компьютер Домен С (добавлен в качестве доверенного узла)

Домен А

Домен В

Рабочая группа

Домен А

√

Домен В

√

Рабочая группа

√

√

Примечания

При управлении удаленным компьютером с компьютера, на котором установлена ОС Windows 7, запустите службу удаленного управления Windows (WinRM), чтобы добавить доверенные узлы. Откройте командную строку с повышенными правами пользователя. Для этого нажмите кнопку Пуск, выберите компоненты Все программы, Стандартные, щелкните правой кнопкой мыши пункт Командная строка и выберите команду Запуск от имени администратора. Введите приведенную ниже команду и нажмите клавишу ВВОД: net start winrm

Для удаленных подключений по сценарию «Рабочая группа — рабочая группа/домен» удаленный компьютер необходимо добавить в список доверенных узлов на исходном компьютере. Для этого введите следующую команду на исходном компьютере в окне командной строки, открытой с повышенными правами пользователя:

winrm set winrm/config/client @{TrustedHosts=»имя_удаленного_компьютера»}

Для удаленных подключений по сценарию «Рабочая группа — рабочая группа/домен», если пользователь не использовал для входа в систему встроенную учетную запись администратора на исходном компьютере, необходимо настроить следующий раздел реестра WinRM, чтобы разрешить удаленный доступ с исходного компьютера. Это изменение необходимо из-за ограничения, налагаемого контролем учетных записей пользователей (UAC) на учетные записи членов группы Администраторы, не являющихся администраторами. Чтобы изменить этот раздел реестра, введите следующую команду на исходном компьютере в командной строке, открытой с повышенными правами пользователя:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

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

winrm s winrm/config/winrs @{MaxShellsPerUser=»X»}

Важно!

Необходимо быть членом группы Администраторы на компьютерах, которыми планируется управлять при помощи диспетчера сервера.

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

Выполнение проверок ролей анализатором соответствия рекомендациям. Дополнительные сведения см. в разделе Выполнение проверок и фильтрация их результатов в анализаторе соответствия рекомендациям.

Просмотр или изменение состояния Программа улучшения качества ПО Windows (CEIP)

Настройка Отчеты об ошибках Windows

Просмотр и изменение информации о брандмауэре Windows

Просмотр сведений о ролях на их домашних страницах и управление ролями
Примечание

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

Просмотр параметров конфигурации Internet Explorer в режиме повышенной безопасности.

Управление службами с домашних страниц ролей.

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

Настройка параметров удаленного рабочего стола

Настройка свойств системы

Проверка наличия новых ролей

Изменение параметров автоматического обновления Windows

Изменение сетевых параметров

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

Изменение параметров конфигурации Internet Explorer в режиме повышенной безопасности

Запуск мастера настройки безопасности, если исходный компьютер — это сервер, работающий под управлением Windows Server 2008 R2

Чтобы защитить серверы от несанкционированного доступа, прежде чем администраторы смогут удаленно подключиться к компьютеру под управлением Windows Server 2008 R2 при помощи Диспетчер серверов, необходимо включить удаленное управление Диспетчер серверов на компьютере назначения.
Перед тем как настроить на сервере удаленное управление при помощи Диспетчер серверов, необходимо включить несколько параметров групповой политики, которые управляют исключениями брандмауэра Windows. Выполните действия, изложенные в разделе Настройка групповой политики для удаленного управления с помощью диспетчера сервера, чтобы убедиться, что параметры групповой политики не переопределяют конфигурацию сервера для удаленного управления.
Примечание

Процедуры этого раздела можно выполнить только на компьютере под управлением Windows Server 2008 R2. Нельзя включить или отключить удаленное управление на компьютере под управлением Windows 7, поскольку ОС Windows 7 нельзя управлять при помощи Диспетчер серверов.

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

На компьютере, предназначенном для удаленного управления, откройте Редактор локальной групповой политики. Для этого нажмите кнопку Пуск, выберите пункт Выполнить, введите gpedit.msc в поле Открыть и нажмите клавишу ВВОД.

Разверните компоненты Конфигурация компьютера, Административные шаблоны, Компоненты Windows, Удаленное управление Windows, а затем выберите Служба WinRM.

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

Выберите Включено и нажмите кнопку ОК.

В древовидном представлении разверните компоненты Параметры Windows, Параметры безопасности, Брандмауэр Windows в режиме повышенной безопасности и выберите Брандмауэр Windows в режиме повышенной безопасности.

Щелкните правой кнопкой мыши пункт Правила для входящих подключений и выберите команду Создать правило.

В мастере создания правила для нового входящего подключения на странице Тип правила выберите Предопределенное.

В выпадающем меню Предопределенное выберите пункт Удаленное управление журналом событий. Нажмите кнопку Далее.

На странице Предопределенные правила нажмите кнопку Далее, чтобы принять новые правила.

На странице Действие выберите пункт Разрешить подключение и нажмите кнопку Готово. По умолчанию выбран вариант Разрешить подключение.

Повторите шаги 5-10, чтобы создать новые правила для входящих подключений для следующих двух дополнительных типов предопределенных правил.

Удаленное управление службой

Удаленное управление брандмауэром Windows

Закройте Редактор локальной групповой политики.

Настройка удаленного управления с помощью диспетчера сервера с использованием интерфейса Windows

На компьютере, предназначенном для удаленного управления, откройте Диспетчер серверов. Чтобы открыть компонент «Управление сервером», нажмите Пуск, Администрирование, а затем Управление сервером.

В области Сводка сервера домашней страницы Диспетчер серверов щелкните команду Настроить удаленное управление с помощью диспетчера сервера.

Выполните одно из указанных ниже действий.

Чтобы разрешить удаленное управление данным компьютером при помощи Диспетчер серверов, установите флажок Разрешить удаленное управление этим сервером с других компьютеров.

Чтобы запретить удаленное управление данным компьютером при помощи Диспетчер серверов, снимите флажок Разрешить удаленное управление этим сервером с других компьютеров.

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

Нажмите кнопку ОК.

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

Удаленное управление службой (именованные каналы — входящий)

Удаленное управление службой (RPC)

Удаленное управление службой (RPC-EPMAP)

Удаленное управление журналом событий (именованные каналы — входящий)

Удаленное управление журналом событий (RPC)

Удаленное управление журналом событий (RPC-EPMAP)

Удаленное управление брандмауэром Windows (RPC)

Удаленное управление брандмауэром Windows (RPC-EPMAP)

Для этого выполните следующие действия.

Откройте оснастку Брандмауэр Windows в режиме повышенной безопасности одним из следующих способов.

В области «Сведения о безопасности» главного окна диспетчера сервера выберите Перейти к брандмауэру Windows.

В древовидном представлении диспетчера сервера разверните раздел Конфигурация и щелкните заголовок Брандмауэр Windows в режиме повышенной безопасности.

В меню Пуск выберите компонент Администрирование, а затем выберите пункт Брандмауэр Windows в режиме повышенной безопасности.

В области Начало работы области сведений компонента Брандмауэр Windows в режиме повышенной безопасности щелкните пункт Правила для входящих подключений.

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

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

На вкладке Общие диалогового окна Свойства правила выберите Включено. Нажмите кнопку ОК.

Примечание

Хотя удаленное управление с помощью диспетчера сервера возможно, даже если исключения для правил брандмауэра «Удаленное управление журналом событий» отключены, удаленные подключения могут работать очень медленно, в зависимости от количества ролей и компонентов, выполняющихся на компьютере, которым вы хотите управлять, если исключения для этих правил брандмауэра не включены. Рекомендуется включить правила брандмауэра «Удаленное управление журналом событий», чтобы избежать задержек в подключении.

Настройка удаленного управления с помощью диспетчера сервера с использованием Windows PowerShell

На компьютере, предназначенном для удаленного управления, откройте сеанс Windows PowerShell с повышенными правами пользователя. Для этого нажмите кнопку Пуск, последовательно выберите компоненты Все программы, Стандартные и Windows PowerShell, затем щелкните правой кнопкой мыши ярлык Windows PowerShell и выберите команду Запуск от имени администратора.

В сеансе Windows PowerShell введите следующую команду и нажмите клавишу ВВОД:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

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

Configure-SMRemoting. ps1 -force -enable

Настройка удаленного управления в ОС Windows Server 2008 R2 в установке Server Core

На компьютере, предназначенном для удаленного управления, в командной строке, которая открывается по умолчанию при входе члена группы Администраторы в систему Windows Server 2008 R2 в установке Server Core, введите следующую команду и нажмите клавишу ВВОД:

Dism.exe /Online /Enable-Feature /FeatureName:NetFx2-ServerCore /FeatureName:MicrosoftWindowsPowerShell /FeatureName:ServerManager-PSH-Cmdlets /FeatureName:BestPractices-PSH-Cmdlets

После завершения установки закройте все приложения и перезагрузите компьютер.

Чтобы убедиться, что Windows PowerShell и командлеты для Диспетчер серверов и анализатора соответствия рекомендациям установлены, попробуйте ввести команду oclist, которая возвращает список всех компонентов Windows, установленных на данном компьютере.

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

В окне командной строки, которое откроется после входа в систему, введите следующую команду, чтобы открыть сеанс Windows PowerShell, и нажмите клавишу ВВОД:

powershell

В сеансе Windows PowerShell введите следующую команду и нажмите клавишу ВВОД:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

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

Configure-SMRemoting.ps1 -force -enable

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

Запустите программу Диспетчер серверов. Чтобы открыть компонент «Управление сервером», нажмите Пуск, Администрирование, а затем Управление сервером.

В древовидном представлении щелкните правой кнопкой мыши узел Диспетчер сервера и выберите команду Подключиться к другому компьютеру.

В диалоговом окне Подключение к другому компьютеру введите имя или IP-адрес другого компьютера, работающего под управлением Windows Server 2008 R2, в поле Другой компьютер или найдите другой сервер в сети при помощи обзора. Нажмите кнопку ОК.

В поле Другой компьютер можно указать NetBIOS-имя, полное доменное имя либо адрес IPv4 или IPv6. Если номер порта не указан, то используется номер порта по умолчанию. Далее приведены примеры форматов, которые можно указать в поле Другой компьютер.

ComputerName

ComputerName:PortNumber

IP-адрес: n.n.n.n

IPv6-адрес: [n:n:n:n]

IPv4-адрес с номером порта: n.n.n.n:PortNumber

IPv6-адрес с номером порта: [n:n:n:n]:PortNumber

Примечание

Если администратор изменил на компьютере номер порта по умолчанию, то нужно открыть нестандартный порт в брандмауэре Windows, чтобы разрешить для этого порта принимать входящие подключения. Порт 5985 открыт по умолчанию, если служба удаленного управления Windows настроена так, как описано в разделе Настройка групповой политики для удаленного управления с помощью диспетчера сервера в этой главе. Нестандартные порты остаются заблокированными, пока не будут открыты. Дополнительные сведения о том, как разблокировать порт в брандмауэре Windows, см. в справке по брандмауэру Windows. Для получения дополнительных сведений о настройке службы удаленного управления Windows в сеансе командной строки введите winrm help и нажмите клавишу ВВОД.

Обратите внимание, что после подключения к удаленному компьютеру имя вашего компьютера изменилось в консоли Диспетчер серверов. Имя компьютера в узле Диспетчер серверов древовидного представления, значение поля Полное имя компьютера в области Сводка сервера Диспетчер серверов и имя компьютера в заголовке консоли меняются на имя удаленного компьютера, к которому вы подключились. Поскольку Диспетчер серверов разрешает IP-адреса в полные доменные имена, то при подключении к удаленному компьютеру с использованием IP-адреса консоль Диспетчер серверов отображает полное доменное имя удаленного компьютера.

Примечание

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

Чтобы выполнить командлет Get-WindowsFeature диспетчера сервера на удаленном компьютере в сеансе Windows PowerShell, выполните следующие действия.

Откройте сеанс Windows PowerShell с повышенными правами пользователя. Для этого нажмите кнопку Пуск, последовательно выберите компоненты Все программы, Стандартные и Windows PowerShell, затем щелкните правой кнопкой мыши ярлык Windows PowerShell и выберите команду Запуск от имени администратора.

Введите следующую команду (где ComputerName - имя удаленного компьютера, работающего под управлением Windows Server 2008 R2, а UserName — имя пользователя, являющегося членом группы Администраторы на удаленном компьютере), затем нажмите клавишу ВВОД:

Enter-PSSession <имя_компьютера> -credential <имя_пользователя>

Будет запрошен пароль, который нужно ввести в защищенном диалоговом окне. Введите пароль и нажмите клавишу ВВОД.

Для загрузки оснастки Диспетчер серверов в сеансе Windows PowerShell введите следующую команду и нажмите клавишу ВВОД:

Import-Module ServerManager

Введите приведенную ниже команду и нажмите клавишу ВВОД:

Get-WindowsFeature

После того, как результаты выполнения командлета Get-WindowsFeature будут показаны в сеансе Windows PowerShell, введите следующую команду, чтобы закрыть сеанс Windows PowerShell, и нажмите клавишу ВВОД:

Exit-PSSession

Можно также создать настраиваемую консоль управления (ММС), содержащую несколько оснасток Диспетчер серверов — каждая для управления отдельным удаленным компьютером.
Для управления несколькими компьютерами с помощью диспетчера сервера и консоли ММС выполните следующие действия.

Чтобы открыть консоль MMC (Microsoft Management Console), нажмите кнопку Пуск, выберите пункт Выполнить, введите mmc и нажмите кнопку ОК.

В меню Файл выберите команду Добавить или удалить оснастку.

В списке Доступные оснастки выберите Диспетчер сервера.

Нажмите кнопку Добавить, чтобы добавить Диспетчер серверов в список Выбранные оснастки.

Повторите предыдущий шаг столько раз, сколько нужно для добавления оснасток Диспетчер серверов в консоль ММС. Нажмите кнопку ОК.

В древовидном представлении новой консоли ММС щелкните правой кнопкой мыши верхний узел оснастки Диспетчер серверов и выберите команду Подключиться к другому компьютеру.

В диалоговом окне Подключение к другому компьютеру введите имя или IP-адрес другого компьютера в поле Другой компьютер или найдите другой сервер в сети при помощи обзора. Нажмите кнопку ОК.

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

Если у вас есть дополнительные оснастки Диспетчер серверов в консоли ММС, повторите данную процедуру, начиная с шага 6, для подключения дополнительных оснасток Диспетчер серверов к другим удаленным компьютерам.

В меню Файл выберите команду Сохранить, чтобы сохранить настраиваемую консоль ММС.

Хотя компьютерами, работающими под управлением Windows 7, нельзя управлять с помощью Диспетчер серверов, можно установить Диспетчер серверов на компьютере под управлением Windows 7, установив для этого Средства администрирования удаленного сервера. Средства администрирования удаленного сервера для Windows 7 можно загрузить на веб-сайте корпорации Майкрософт (http://go.microsoft.com/fwlink/?LinkId=131280). После установки Средства администрирования удаленного сервера можно подключить консоль Диспетчер серверов к удаленному компьютеру под управлением Windows Server 2008 R2 и выполнять задачи управления на сервере назначения, который определен в пункте Задачи, которые можно выполнять на удаленном сервере при помощи диспетчера сервера настоящего раздела.
Установив Средства администрирования удаленного сервера на компьютере под управлением Windows 7, так же как на компьютере под управлением Windows Server 2008 R2, можно создать настраиваемую консоль ММС Диспетчер серверов для управления несколькими удаленными компьютерами, на которых установлен Windows Server 2008 R2. Чтобы создать настраиваемую консоль ММС Диспетчер серверов на компьютере, где установлены ОС Windows 7 и Средства администрирования удаленного сервера, см. пункт Управление несколькими компьютерами с помощью диспетчера сервера и консоли ММС настоящего раздела.
Для удаленного управления с компьютера, на котором установлена ОС Windows 7, выполните следующие действия.

Установите Средства администрирования удаленного сервера на компьютере под управлением Windows 7.

Загрузите пакет Средства администрирования удаленного сервера с веб-сайта корпорации Майкрософт и затем следуйте инструкциям по установке Средства администрирования удаленного сервера, приведенным на странице Центра загрузки.

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

После установки Средства администрирования удаленного сервера откройте Диспетчер серверов. Чтобы открыть компонент «Управление сервером», нажмите Пуск, Администрирование, а затем Управление сервером.

В древовидном представлении щелкните правой кнопкой мыши узел Диспетчер сервера и выберите команду Подключиться к другому компьютеру.

В диалоговом окне Подключение к другому компьютеру введите имя или IP-адрес компьютера, работающего под управлением Windows Server 2008 R2, в поле Другой компьютер или найдите другой сервер в сети при помощи обзора. Нажмите кнопку ОК.

Обратите внимание, что после подключения к удаленному компьютеру имя компьютера появится в консоли Диспетчер серверов. Вы увидите имя удаленного компьютера, к которому подключены, в узле Диспетчер серверов древовидного представления, в поле Полное имя компьютера области Сводка сервера Диспетчер серверов и имя компьютера в заголовке консоли.

Запуск удаленных команд — PowerShell
000Z» data-article-date-source=»ms.date»> 21.08.2020
3 минуты на чтение
В этой статье
Вы можете запускать команды на одном или сотнях компьютеров с помощью одной команды PowerShell. Windows PowerShell поддерживает удаленные вычисления с использованием различных технологий, включая WMI, RPC и WS-Management.
PowerShell Core поддерживает удаленное взаимодействие WMI, WS-Management и SSH.В PowerShell 6 RPC больше не поддерживается. В PowerShell 7 и выше RPC поддерживается только в Windows.
Дополнительные сведения об удаленном взаимодействии в PowerShell Core см. В следующих статьях:
Удаленное взаимодействие Windows PowerShell без конфигурации
Многие командлеты Windows PowerShell имеют параметр ComputerName, который позволяет собирать данные и изменить настройки на одном или нескольких удаленных компьютерах. Эти командлеты используют разные протоколы связи. и работать на всех операционных системах Windows без какой-либо специальной настройки.
Эти командлеты включают:
Как правило, командлеты, поддерживающие удаленное взаимодействие без специальной настройки, имеют имя компьютера. параметр и не имеют параметра сеанса. Чтобы найти эти командлеты в сеансе, введите:
Get-Command | где {$ _. parameters.keys -contains "ComputerName" -and $ _. parameters.keys -notcontains "Session"}
Удаленное взаимодействие с Windows PowerShell
Используя протокол WS-Management, удаленное взаимодействие Windows PowerShell позволяет запускать любую оболочку Windows PowerShell. команда на одном или нескольких удаленных компьютерах.Вы можете установить постоянные соединения, начать интерактивный сеансов и запускать сценарии на удаленных компьютерах.
Чтобы использовать удаленное взаимодействие Windows PowerShell, удаленный компьютер должен быть настроен для удаленного управления. Дополнительные сведения, включая инструкции, см. В разделе «О требованиях удаленного доступа».
После настройки удаленного взаимодействия Windows PowerShell вам станут доступны многие стратегии удаленного взаимодействия. В этой статье перечислены лишь некоторые из них. Дополнительные сведения см. В разделе «О Remote».
Начать интерактивный сеанс
Чтобы начать интерактивный сеанс с одним удаленным компьютером, используйте Enter-PSSession командлет.Например, чтобы начать интерактивный сеанс с удаленным компьютером Server01, введите:
Enter-PSSession Server01
В командной строке отображается имя удаленного компьютера. Любые команды, которые вы вводите в приглашение запускается на удаленном компьютере, а результаты отображаются на локальном компьютере.
Чтобы завершить интерактивный сеанс, введите:
Exit-PSSession
Дополнительные сведения о командлетах Enter-PSSession и Exit-PSSession см .:
Выполнить удаленную команду
Чтобы запустить команду на одном или нескольких компьютерах, используйте Invoke-Command командлет.Например, чтобы запустить Get-UICulture на удаленных компьютерах Server01 и Server02 введите:
Invoke-Command -ComputerName Server01, Server02 -ScriptBlock {Get-UICulture}
Результат возвращается на ваш компьютер.
Имя LCID DisplayName PSComputerName ---- ---- ----------- -------------- 1033 en-US Английский (США) server01.corp.fabrikam.com 1033 en-US Английский (США) server02.corp.fabrikam.com
Запустить сценарий
Чтобы запустить сценарий на одном или нескольких удаленных компьютерах, используйте параметр FilePath команды Invoke-Command командлет. Сценарий должен быть на вашем локальном компьютере или доступен для него. Результаты возвращаются на ваш локальный компьютер.
Например, следующая команда запускает сценарий DiskCollect.ps1 на удаленных компьютерах Server01 и Server02.
Invoke-Command -ComputerName Server01, Server02 -FilePath c: \ Scripts \ DiskCollect.ps1
Установить постоянное соединение
Используйте командлет New-PSSession для создания постоянного сеанса на удаленном компьютере. Следующее пример создает удаленные сеансы на Server01 и Server02. Объекты сеанса хранятся в $ s Переменная.
$ s = New-PSSession -ComputerName Server01, Server02
Теперь, когда сеансы установлены, вы можете запускать в них любую команду. И потому что сеансы постоянный, вы можете собирать данные из одной команды и использовать их в другой команде.
Например, следующая команда запускает команду Get-HotFix в сеансах в переменной $ s и он сохраняет результаты в переменной $ h. Переменная $ h создается в каждой из сессий в $ s, но его нет в локальной сессии.
Invoke-Command -Session $ s {$ h = Get-HotFix}
Теперь вы можете использовать данные в переменной $ h с другими командами в том же сеансе. Результаты, достижения отображаются на локальном компьютере. Например:
Invoke-Command -Session $ s {$ h | где {$ _.Установлено -ne "NTAUTHORITY \ SYSTEM"}}
Расширенное удаленное взаимодействие
Удаленное управление Windows PowerShell здесь только начинается. С помощью командлетов, установленных с Windows PowerShell, вы можете устанавливать и настраивать удаленные сеансы как с локальной, так и с удаленной стороны, создавать настраиваемые и ограниченные сеансы, позволять пользователям импортировать команды из удаленного сеанса, который фактически запускать неявно в удаленном сеансе, настраивать безопасность удаленного сеанса и многое другое более.
Windows PowerShell включает поставщика WSMan.Провайдер создает диск WSMAN: , который позволяет перемещаться по иерархии параметров конфигурации на локальном и удаленных компьютерах.
Дополнительные сведения о поставщике WSMan см. Провайдер WSMan и О командлетах WS-Management, или в консоли Windows PowerShell введите Get-Help wsman .
Для получения дополнительной информации см .:
Для получения справки об ошибках удаленного взаимодействия см. About_Remote_Troubleshooting.
См. Также
Restart-Computer (Microsoft.PowerShell.
Management) — PowerShell | Документы Microsoft
Перезапускает операционную систему на локальном и удаленном компьютерах.
В этой статье
Синтаксис
Перезагрузка компьютера [-WsmanAuthentication ] [[-ComputerName] ] [[-Credential] ] [-Сила] [-Ждать] [-Timeout ] [-For ] [-Delay ] [-Что, если] [-Подтверждать] [<Общие параметры>]
Описание
Командлет Restart-Computer перезапускает операционную систему на локальном и удаленном компьютерах.
Вы можете использовать параметры Restart-Computer для запуска операций перезагрузки, чтобы указать уровни аутентификации и альтернативные учетные данные, чтобы ограничить операции, выполняемые одновременно, и вызвать немедленный перезапуск.
Начиная с Windows PowerShell 3. 0, вы можете дождаться завершения перезагрузки, прежде чем запускать следующий команда. Укажите тайм-аут ожидания и интервал запроса, а также дождитесь, пока будут доступно на перезагруженном компьютере.Эта функция делает практичным использование Restart-Computer в скрипты и функции.
Примеры
Пример 1: Перезагрузите локальный компьютер
Restart-Computer перезагружает локальный компьютер.
Перезагрузка компьютера
Пример 2: Перезагрузка нескольких компьютеров
Restart-Computer может перезагружать удаленные и локальные компьютеры. Параметр ComputerName принимает массив имен компьютеров.
Перезагрузка компьютера-Имя компьютера Server01, Server02, localhost
Пример 3: Получить имена компьютеров из текстового файла
Restart-Computer получает список имен компьютеров из текстового файла и перезагружает компьютеры. В ComputerName параметр не указан. Но поскольку это первый параметр позиции, он принимает имена компьютеров из текстового файла, которые отправляются по конвейеру.
Get-Content-Путь C: \ Domain01.txt | Перезагрузка-компьютер
Get-Content использует параметр Path для получения списка имен компьютеров из текстового файла, Домен01.txt . Имена компьютеров отправляются по конвейеру. Restart-Computer перезагружает каждый компьютер.
Пример 4: Принудительный перезапуск компьютеров, перечисленных в текстовом файле
В этом примере выполняется немедленная перезагрузка компьютеров, перечисленных в файле Domain01.txt . В имена компьютеров из текстового файла хранятся в переменной.Параметр Force заставляет немедленный перезапуск.
$ Names = Get-Content -Path C: \ Domain01.txt $ Creds = Get-Credential Перезагрузите компьютер -ComputerName $ Names -Credential $ Creds -Force
Get-Content использует параметр Path для получения списка имен компьютеров из текстового файла, Домен01. txt . Имена компьютеров хранятся в переменной $ Names . Get-Credential подсказки вам для имени пользователя и пароля и сохраняет значения в переменной $ Creds . Перезагрузка компьютера использует параметры ComputerName и Credential с их переменными. Модель Force Параметр вызывает немедленную перезагрузку каждого компьютера.
Пример 6: Перезагрузите удаленный компьютер и дождитесь PowerShell
Restart-Computer перезагружает удаленный компьютер и затем ждет до 5 минут (300 секунд) в течение PowerShell станет доступным на перезагруженном компьютере, прежде чем он продолжит работу.
Перезагрузка-компьютер -ComputerName Server01 -Wait -For PowerShell -Timeout 300 -Delay 2
Restart-Computer использует параметр ComputerName для указания Server01 . Подождите Параметр ожидает завершения перезапуска. For указывает, что PowerShell может запускать команды на удаленный компьютер. Параметр Timeout указывает пятиминутное ожидание. Параметр Delay каждые две секунды опрашивает удаленный компьютер, чтобы определить, перезагружен ли он.
Пример 7: Перезагрузите компьютер с помощью WsmanAuthentication
Restart-Computer перезагружает удаленный компьютер с помощью механизма WsmanAuthentication .Проверка подлинности Kerberos определяет, есть ли у текущего пользователя разрешение на перезапуск удаленного компьютера. компьютер. Для получения дополнительной информации см. AuthenticationMechanism.
Restart-Computer -ComputerName Server01 -WsmanAuthentication Kerberos
Restart-Computer использует параметр ComputerName для указания удаленного компьютера, Server01 . Параметр WsmanAuthentication указывает метод проверки подлинности как Kerberos .
Параметры
— ИмяКомпьютера
Задает одно имя компьютера или массив имен компьютеров, разделенных запятыми. Перезагрузка-компьютер принимает ComputerName объектов из конвейера или переменных.
Введите имя NetBIOS, IP-адрес или полное доменное имя удаленного компьютера. К укажите локальный компьютер, введите имя компьютера, точку . или localhost.
Этот параметр не зависит от удаленного взаимодействия PowerShell.Вы можете использовать параметр ComputerName даже если ваш компьютер не настроен для выполнения удаленных команд.
Если параметр ComputerName не указан, Restart-Computer перезагружает локальный компьютер.
Принять
Тип: Строка []
Псевдонимы: CN, __SERVER, Server, IPAddress
Позиция: 0
Конвейер
Значение по умолчанию: ввод: True
Принимать подстановочные символы: False
-Confirm
Запрашивает подтверждение перед запуском Restart-Computer .
903
Тип: SwitchParameter
Псевдонимы: cf
Позиция: Именованный
Значение по умолчанию: Ложный
Принимать подстановочные знаки: Ложь
-Credential
Задает учетную запись пользователя, у которой есть разрешение на выполнение этого действия. По умолчанию это текущий пользователь.
Введите имя пользователя, например User01 или Domain01 \ User01 , или введите объект PSCredential генерируется командлетом Get-Credential . Если вы введете имя пользователя, вам будет предложено ввести пароль.
Учетные данные хранятся в PSCredential объект, а пароль хранится как SecureString.
Тип: PSCredential
Позиция: 1
Значение по умолчанию: Текущий пользователь
Принять ввод конвейера: Ложный
-Задержка
Задает частоту запросов в секундах. PowerShell запрашивает службу, указанную в Для параметра , определяющего, доступна ли служба после перезапуска компьютера.
Этот параметр действителен только вместе с параметрами Ожидание, и Для параметров .
Этот параметр появился в Windows PowerShell 3.0.
Если параметр Delay не указан, Restart-Computer использует пятисекундную задержку.
Тип: Int16
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный Ложный подстановочный знак : Ложный подстановочный знак
-Для
Определяет поведение PowerShell при ожидании, когда указанная служба или функция станет доступно после перезагрузки компьютера.Этот параметр действителен только с параметром Ожидание .
Допустимые значения этого параметра:
По умолчанию : ожидает перезапуска PowerShell.
PowerShell : Может запускать команды в удаленном сеансе PowerShell на компьютере.
WMI : получает ответ на запрос Win32_ComputerSystem для компьютера.
WinRM : Можно установить удаленный сеанс с компьютером с помощью WS-Management.
Этот параметр появился в Windows PowerShell 3.0.
Тип: WaitForServiceTypes
Допустимые значения: Wmi, WinRM, PowerShell
Позиция: Именованный ввод
Значение по умолчанию
Значение по умолчанию: Ложь
Принимать подстановочные знаки: Ложь
-Force
Вызывает немедленную перезагрузку компьютера.
Тип: SwitchParameter
Псевдонимы: f
Позиция: Именованный
Значение по умолчанию: Нет
Ложный ввод Принимать подстановочные знаки: False
-Timeout
Задает продолжительность ожидания в секундах. По истечении тайм-аута Restart-Computer возвращается. в командную строку, даже если компьютеры не перезагружены.
Параметр Тайм-аут действителен только с параметром Ожидание . Тайм-аут отменяет Ожидание Неопределенный период ожидания параметра .
Этот параметр появился в Windows PowerShell 3.0.
Тип: Int32
Псевдонимы: TimeoutSec
Позиция: Именованный
Значение по умолчанию: Нет Ложный вход Принимать подстановочные знаки: Ложь
-Wait
Restart-Computer подавляет запрос PowerShell и блокирует конвейер, пока компьютеры перезапущен.Вы можете использовать этот параметр в сценарии, чтобы перезагрузить компьютеры, а затем продолжить обработку. когда перезапуск закончится.
Параметр Wait ожидает неограниченное время перезапуска компьютеров. Вы можете использовать Timeout to отрегулируйте время и параметры для и Delay , чтобы дождаться, пока определенные службы станут доступно на перезагруженных компьютерах.
Параметр Wait недействителен при перезагрузке локального компьютера.Если значение ComputerName параметр содержит имена удаленных компьютеров и локального компьютера, Restart-Computer генерирует непрекращающуюся ошибку для Подождите на локальном компьютере, но ждет для перезапуска удаленных компьютеров.
Этот параметр появился в Windows PowerShell 3.0.
Тип: SwitchParameter
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный
-WhatIf
Показывает, что произойдет, если запустится Restart-Computer . Командлет Restart-Computer не запущен.
903
Тип: SwitchParameter
Псевдонимы: wi
Позиция: Именованный
Значение по умолчанию: Ложный
Принимать подстановочные знаки: Ложь
-WsmanAuthentication
Задает механизм, используемый для аутентификации учетных данных пользователя.Этот параметр был введена в Windows PowerShell 3.0.
Допустимые значения для этого параметра: Basic , CredSSP , Default , Digest , Kerberos и Согласование .
Для получения дополнительной информации см. AuthenticationMechanism.
Предупреждение
Проверка подлинности поставщика услуг безопасности учетных данных (CredSSP), в которой учетные данные пользователя передается на удаленный компьютер для проверки подлинности, предназначен для команд, требующих проверка подлинности более чем на одном ресурсе, например доступ к удаленному сетевому ресурсу.Этот механизм увеличивает риск безопасности удаленной работы. Если удаленный компьютер скомпрометирован, передаваемые ему учетные данные могут использоваться для управления сетевым сеансом.
Тип: Строка
Допустимые значения: Базовый, CredSSP, По умолчанию, Дайджест, Kerberos, Согласование
Позиция: Именованный
Значение по умолчанию: Принять ввод конвейера: Ложь
Принимать подстановочные знаки: Ложь
Входы
Строка
Restart-Computer принимает имена компьютеров из конвейера или переменных.
Выходы
Нет
Restart-Computer не генерирует никаких выходных данных.
Банкноты
В Windows Restart-Computer использует метод Win32Shutdown инструментария управления Windows (WMI) Win32_OperatingSystem учебный класс. Этот метод требует, чтобы для учетной записи пользователя была включена привилегия SeShutdownPrivilege . используется для перезапуска машины.
В Linux и Mac OS, Restart-Computer использует инструмент bash / sbin / shutdown .
Удаленное взаимодействие PowerShell через SSH — PowerShell
19.10.2020
6 минут на чтение
В этой статье
Обзор
Удаленное взаимодействие PowerShell обычно использует WinRM для согласования подключения и передачи данных. SSH сейчас доступно для платформ Linux и Windows и обеспечивает истинное многоплатформенное удаленное взаимодействие PowerShell.
WinRM обеспечивает надежную модель размещения для удаленных сеансов PowerShell. Удаленное взаимодействие на основе SSH не работает в настоящее время поддерживает конфигурацию удаленной конечной точки и Just Enough Administration (JEA).
Удаленное взаимодействие по SSH позволяет выполнять базовое удаленное взаимодействие сеансов PowerShell между компьютерами Windows и Linux. SSH Удаленное взаимодействие создает хост-процесс PowerShell на целевом компьютере в качестве подсистемы SSH. В итоге мы реализуем общую модель хостинга, аналогичную WinRM, для поддержки конфигурации конечной точки и JEA.
Командлеты New-PSSession , Enter-PSSession и Invoke-Command теперь имеют новый параметр, равный поддержите это новое удаленное соединение.
[-HostName ] [-UserName ] [-KeyFilePath ]
Чтобы создать удаленный сеанс, вы указываете целевой компьютер с параметром HostName и укажите имя пользователя UserName . При интерактивном запуске командлетов вам будет предложено ввести пароль.Вы также можете использовать аутентификацию по ключу SSH, используя файл закрытого ключа с KeyFilePath параметр. Создание ключей для аутентификации SSH зависит от платформы.
Общая информация по настройке
PowerShell 6 или более поздней версии, и SSH должен быть установлен на всех компьютерах. Установите оба клиента SSH ( ssh.exe ) и сервер ( sshd.exe ), чтобы вы могли удаленно подключаться к компьютерам и с них. OpenSSH для Windows теперь доступна в Windows 10 build 1809 и Windows Server 2019.Для получения дополнительной информации см. Управляйте Windows с помощью OpenSSH. Для Linux, установите SSH, включая sshd-сервер, подходящий для вашей платформы. Вам также необходимо установить PowerShell от GitHub, чтобы получить функцию удаленного взаимодействия по SSH. Сервер SSH должен быть настроен для создания подсистема SSH для размещения процесса PowerShell на удаленном компьютере. И вы должны включить пароль или аутентификация на основе ключа .
Установка на компьютере под управлением Windows
Установите последнюю версию PowerShell.Для получения дополнительной информации см. Установка PowerShell Core в Windows.
Вы можете подтвердить, что PowerShell поддерживает удаленное взаимодействие SSH, указав параметр New-PSSession наборы. Вы заметите, что есть имена наборов параметров, которые начинаются с SSH . Эти наборы параметров включить параметров SSH .
(Get-Command New-PSSession) .ParameterSets.Name
Имя ---- SSHHost SSHHostHashParam
Установите последнюю версию Win32 OpenSSH.Инструкции по установке см. Начало работы с OpenSSH.
Отредактируйте файл sshd_config , расположенный по адресу $ env: ProgramData \ ssh .
Убедитесь, что аутентификация по паролю включена:
Пароль Аутентификация да
Создайте подсистему SSH, в которой размещается процесс PowerShell на удаленном компьютере:
Подсистема powershell c: /progra~1/powershell/7/pwsh.exe -sshs -NoLogo
Примечание
По умолчанию исполняемый файл PowerShell находится в c: / program ~ 1 / powershell / 7 / pwsh.exe . В расположение может отличаться в зависимости от того, как вы установили PowerShell.
Вы должны использовать короткое имя 8.3 для всех путей к файлам, содержащих пробелы. Есть ошибка в OpenSSH для Windows, который предотвращает работу пробелов в исполняемых путях подсистемы. Для большего информацию см. в этом выпуске GitHub.
Краткое имя 8.3 для папки Program Files в Windows обычно Progra ~ 1 . Тем не мение, вы можете использовать следующую команду, чтобы убедиться:
Get-CimInstance Win32_Directory -Filter 'Name = "C: \\ Program Files"' | Выбрать объект EightDotThreeFileName
EightDotThreeFileName --------------------- c: \ Program ~ 1
Дополнительно можно включить аутентификацию по ключу:
Pubkey Аутентификация да
Для получения дополнительной информации см. Управление ключами OpenSSH.
Перезапустите службу sshd .
Restart-Service sshd
Добавьте путь, по которому установлен OpenSSH, в переменную среды Path. Например, C: \ Program Files \ OpenSSH \ . Эта запись позволяет найти ssh.exe .
Установка на компьютере под управлением Linux с Ubuntu 16.04
Установите последнюю версию PowerShell, см. Установка PowerShell Core в Linux.
Установите Ubuntu OpenSSH Server.
sudo apt установить openssh-client sudo apt установить openssh-server
Отредактируйте файл sshd_config в расположении / etc / ssh .
Убедитесь, что аутентификация по паролю включена:
Пароль Аутентификация да
Дополнительно можно включить аутентификацию по ключу:
Pubkey Аутентификация да
Для получения дополнительной информации о создании ключей SSH в Ubuntu см. Справочную страницу для ssh-keygen.
Добавить запись подсистемы PowerShell:
Подсистема powershell / usr / bin / pwsh -sshs -NoLogo
Примечание
Расположение исполняемого файла PowerShell по умолчанию — / usr / bin / pwsh . Расположение может отличаться в зависимости от того, как вы установили PowerShell.
Дополнительно можно включить аутентификацию по ключу:
Pubkey Аутентификация да
Перезапустите службу ssh .
sudo service ssh перезапуск
Настройка на компьютере MacOS
Установите последнюю версию PowerShell.Для дополнительной информации, Установка PowerShell Core на macOS.
Убедитесь, что удаленное взаимодействие SSH включено, выполнив следующие действия:
Открыть Системные настройки .
Щелкните Sharing .
Установите флажок Remote Login , чтобы установить Remote Login: на .
Разрешить доступ соответствующим пользователям.
Отредактируйте файл sshd_config в расположении / private / etc / ssh / sshd_config .
Используйте текстовый редактор, например nano :
Судо нано / частный / и т. Д. / Ssh / sshd_config
Убедитесь, что аутентификация по паролю включена:
Пароль Аутентификация да
Добавить запись подсистемы PowerShell:
Подсистема powershell / usr / local / bin / pwsh -sshs -NoLogo
Примечание
По умолчанию исполняемый файл PowerShell находится в / usr / local / bin / pwsh . Расположение может зависят от того, как вы установили PowerShell.
Дополнительно можно включить аутентификацию по ключу:
Pubkey Аутентификация да
Перезапустите службу sshd .
sudo launchctl stop com.openssh.sshd sudo launchctl start com.openssh.sshd
Аутентификация
Удаленное взаимодействие PowerShell через SSH полагается на обмен аутентификацией между SSH-клиентом и SSH сервис и не реализует никаких схем аутентификации.В результате любой настроенный схемы аутентификации, включая многофакторную аутентификацию, обрабатываются SSH и не зависят от PowerShell. Например, вы можете настроить службу SSH на требование аутентификации с открытым ключом и одноразовый пароль для дополнительной безопасности. Конфигурация многофакторной аутентификации находится за пределами объем данной документации. Обратитесь к документации по SSH, чтобы узнать, как правильно настроить многофакторная проверка подлинности и проверка ее работы вне PowerShell, прежде чем пытаться ее использовать с удаленным взаимодействием PowerShell.
Примечание
Пользователи сохраняют те же привилегии в удаленных сеансах. Это означает, что администраторы имеют доступ к повышенная оболочка, а обычных пользователей не будет.
Пример удаленного взаимодействия PowerShell
Самый простой способ проверить удаленное взаимодействие — это попробовать его на одном компьютере. В этом примере мы создаем удаленный сеанс обратно на тот же компьютер Linux. Мы используем командлеты PowerShell в интерактивном режиме, поэтому см. запросы от SSH с просьбой подтвердить хост-компьютер и запросом пароля.Вы можете сделать То же самое на компьютере с Windows для обеспечения работы удаленного взаимодействия. Затем удаленное между компьютерами изменение имени хоста.
# Linux в Linux # $ session = New-PSSession -HostName UbuntuVM1 -UserName TestUser
Подлинность хоста UbuntuVM1 (9.129.17.107) не может быть установлена. Отпечаток ключа ECDSA - SHA256: 2kCbnhT2dUE6WCGgVJ8Hyfu1z2wE4lifaJXLO7QJy0Y. Вы уверены, что хотите продолжить подключение (да / нет)? Пароль TestUser @ UbuntuVM1s:
$ сессия
Id Name ComputerName ComputerType State ConfigurationName Доступность - ---- ------------ ------------ ----- --------------- - ------------ 1 SSh2 UbuntuVM1 RemoteMachine Открыт DefaultShell Доступен
Enter-PSSession $ session
[UbuntuVM1]: PS / home / TestUser> uname -a Linux TestUser-UbuntuVM1 4.2.0-42-generic 49 ~ 16.04.1-Ubuntu SMP среда 29 июня 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux [UbuntuVM1]: PS / home / TestUser> Exit-PSSession
Invoke-Command $ session -ScriptBlock {Get-Process powershell}
Обрабатывает NPM (K) PM (K) WS (K) Идентификатор процессора (ов) SI ProcessName PSComputerName ------- ------ ----- ----- ------ - - ----------- ------ -------- 0 0 0 19 3.23 10635 635 PowerShell UbuntuVM1 0 0 0 21 4.92 11033017 PowerShell UbuntuVM1 0 0 0 20 3.07 11076776 Powershell UbuntuVM1
# # Linux в Windows # Enter-PSSession -HostName WinVM1 -UserName PTestName
PTestName @ WinVM1s пароль:
[WinVM1]: PS C: \ Users \ PTestName \ Documents> cmd / c ver
Microsoft Windows [Версия 10.0,10586]
# # Windows в Windows # C: \ Users \ PSUser \ Documents> pwsh.exe
PowerShell Авторское право (c) Корпорация Microsoft. Все права защищены.
$ session = New-PSSession -HostName WinVM2 -UserName PSRemoteUser
Подлинность хоста WinVM2 (10.13.37.3) не может быть установлена. Отпечаток ключа ECDSA - SHA256: kSU6slAROyQVMEynVIXAdxSiZpwDBigpAF / TXjjWjmw. Вы уверены, что хотите продолжить подключение (да / нет)? Предупреждение: постоянно добавленный WinVM2,10.13.37.3 '(ECDSA) в список известных хостов. Пароль PSRemoteUser @ WinVM2:
$ сессия
Id Name ComputerName ComputerType State ConfigurationName Доступность - ---- ------------ ------------ ----- --------------- - ------------ 1 SSh2 WinVM2 RemoteMachine Открыт DefaultShell Доступен
Enter-PSSession -Session $ session
[WinVM2]: PS C: \ Users \ PSRemoteUser \ Documents> $ PSVersionTable Имя Значение ---- ----- Ядро PSEdition PSCompatibleVersions {1.0, 2.0, 3.0, 4.0 ...} Сериализация Версия 1.1.0.1 Версия сборки 3.0.0.0 CLRVersion PS Версия 6.0.0-альфа WSManStackVersion 3.0 PSRemotingProtocolВерсия 2.3 GitCommitId v6.0.0-alpha.17 [WinVM2]: PS C: \ Users \ PSRemoteUser \ Documents>
Ограничения
Команда sudo не работает в удаленном сеансе связи с компьютером Linux.
PSПеремещение через SSH не поддерживает профили и не имеет доступа к $ PROFILE .Однажды в сеанс, вы можете загрузить профиль, указав в профиле полный путь к файлу через точку. Это не связанных с профилями SSH. Вы можете настроить SSH-сервер на использование PowerShell в качестве оболочки по умолчанию. и загрузить профиль через SSH. См. Дополнительную информацию в документации по SSH.
До PowerShell 7.1 удаленное взаимодействие через SSH не поддерживало удаленные сеансы второго перехода. Этот возможность была ограничена сеансами с использованием WinRM. PowerShell 7.1 позволяет Enter-PSSession и Enter-PSHostProcess для работы из любого интерактивного удаленного сеанса.
См. Также
Установка PowerShell Core в Linux
Установка PowerShell Core на macOS
Установка PowerShell Core в Windows
Управление Windows с помощью OpenSSH
Управление ключами OpenSSH
Ubuntu SSH
Удаленное взаимодействие WS-Management (WSMan) в PowerShell Core — PowerShell
06.08.2018
2 минуты на чтение
В этой статье
Инструкции по созданию конечной точки удаленного взаимодействия
Пакет PowerShell Core для Windows включает подключаемый модуль WinRM ( pwrshplugin.dll ) и скрипт установки ( Install-PowerShellRemoting.ps1 ) в $ PSHome . Эти файлы включают PowerShell принимать входящие удаленные подключения PowerShell, когда указана его конечная точка.
Мотивация
Установка PowerShell позволяет устанавливать сеансы PowerShell на удаленные компьютеры, используя New-PSSession и Enter-PSSession . Чтобы включить прием входящего удаленного PowerShell подключений, пользователь должен создать конечную точку удаленного взаимодействия WinRM.Это сценарий явного согласия где пользователь запускает Install-PowerShellRemoting.ps1 для создания конечной точки WinRM. Установка скрипт является краткосрочным решением, пока мы не добавим дополнительные функции в Enable-PS. выполнить то же действие. Для получения дополнительной информации см. Проблему №1193.
Действия сценария
Скрипт
Создает каталог для подключаемого модуля в $ env: windir \ System32 \ PowerShell
Копирует pwrshplugin.dll в это место
Создает файл конфигурации
Регистрирует этот плагин с WinRM
Регистрация
Сценарий должен выполняться в сеансе PowerShell на уровне администратора и работать в двух режимах.
Выполняется экземпляром PowerShell, который регистрирует
Install-PowerShellRemoting.ps1
Выполняется другим экземпляром PowerShell от имени экземпляра, который он зарегистрирует.
<путь к PowerShell> \ Install-PowerShellRemoting.ps1 -PowerShellHome "<абсолютный путь к $ PSHOME экземпляра>"
Например:
Set-Location -Path 'C: \ Program Files \ PowerShell \ 6.0.0 \' . \ Install-PowerShellRemoting.ps1 -PowerShellHome "C: \ Program Files \ PowerShell \ 6.0.0 \"
Примечание
Сценарий удаленной регистрации перезапускает WinRM. Все существующие сеансы PSRP завершены сразу после запуска скрипта. При запуске во время удаленного сеанса сценарий завершает связь.
Как подключиться к новой конечной точке
Создайте сеанс PowerShell для новой конечной точки PowerShell, указав -ConfigurationName "какое-то имя конечной точки" . Чтобы подключиться к экземпляру PowerShell из примера выше, используйте либо:
New-PSSession ... -ConfigurationName "powershell.6.0.0" Введите-PSSession ... -ConfigurationName "powershell.6.0.0"
Обратите внимание, что вызовы New-PSSession и Enter-PSSession , в которых не указано -ConfigurationName будет нацелен на конечную точку PowerShell по умолчанию, microsoft.Powershell .
New-PSSession (Microsoft.PowerShell.Core) - PowerShell | Документы Microsoft
Создает постоянное соединение с локальным или удаленным компьютером.
В этой статье
Синтаксис
New-PSSession [[-ComputerName] ] [-Credential ] [-Name ] [-EnableNetworkAccess] [-ConfigurationName ] [-Порт ] [-UseSSL] [-ApplicationName ] [-ThrottleLimit ] [-SessionOption ] [-Authentication ] [-CertificateThumbprint ] [<Общие параметры>]
New-PSSession [-Credential ] [-Name ] [-EnableNetworkAccess] [-ConfigurationName ] [-ThrottleLimit ] [-ConnectionUri] [-AllowRedirection] [-SessionOption ] [-Authentication ] [-CertificateThumbprint ] [<Общие параметры>]
New-PSSession -Credential [-Name ] [-ConfigurationName ] [-VMId] [-ThrottleLimit ] [<Общие параметры>]
New-PSSession -Credential [-Name ] [-ConfigurationName ] -VMName [-ThrottleLimit ] [<Общие параметры>]
New-PSSession [[-Сессия] ] [-Name ] [-EnableNetworkAccess] [-ThrottleLimit ] [<Общие параметры>]
New-PSSession [-Name ] [-ConfigurationName ] -ContainerId [-Запустить от имени администратора] [-ThrottleLimit ] [<Общие параметры>]
New-PSSession [-Name ] [-UseWindowsPowerShell] [<Общие параметры>]
New-PSSession [-Name ] [-Порт ] [-HostName] [-UserName ] [-KeyFilePath ] [-SSHTransport] [-Подсистема ] [<Общие параметры>]
New-PSSession [-Name ] -SSHConnection <Хеш-таблица []> [<Общие параметры>]
Описание
Командлет New-PSSession создает сеанс PowerShell ( PSSession ) на локальном или удаленном компьютер.Когда вы создаете PSSession , PowerShell устанавливает постоянное соединение с удаленный компьютер.
Используйте PSSession для запуска нескольких команд, которые совместно используют данные, такие как функция или значение Переменная. Для выполнения команд в сеансе PSSession используйте командлет Invoke-Command . Чтобы использовать PSSession для прямого взаимодействия с удаленным компьютером используйте командлет Enter-PSSession . За дополнительную информацию см. в about_PSSessions.
Вы можете запускать команды на удаленном компьютере без создания сеанса PSSession , используя ComputerName параметры Enter-PSSession или Invoke-Command . Когда вы используете ComputerName параметр, PowerShell создает временное соединение, которое используется для команды а затем закрывается.
Начиная с PowerShell 6.0 вы можете использовать Secure Shell (SSH) для установления соединения и создания сеанс на удаленном компьютере, если SSH доступен на локальном компьютере, а удаленный компьютер настроен с помощью конечной точки PowerShell SSH.Преимущество удаленного сеанса PowerShell на основе SSH: что он может работать на нескольких платформах (Windows, Linux, macOS). Для сеансов на основе SSH вы используете набор параметров HostName или SSHConnection для указания удаленного компьютера и соответствующего информация о подключении. Дополнительные сведения о настройке удаленного взаимодействия PowerShell SSH см. В разделе Удаленное взаимодействие PowerShell через SSH.
Примечание
При использовании удаленного взаимодействия WSMan с клиента Linux или macOS с конечной точкой HTTPS, где сервер сертификат не является доверенным (например,g., самоподписанный сертификат). Вы должны предоставить PSSessionOption который включает -SkipCACheck и -SkipCNCheck для успешного установления соединения. Только делать это, если вы находитесь в среде, где вы можете быть уверены в сертификате сервера и сетевое подключение к целевой системе.
Примеры
Пример 1. Создание сеанса на локальном компьютере
$ s = Новый сеанс PSSession
Эта команда создает новый сеанс PSSession на локальном компьютере и сохраняет сеанс PSSession в $ s переменная.
Теперь вы можете использовать этот PSSession для выполнения команд на локальном компьютере.
Пример 2: Создание сеанса на удаленном компьютере
$ Server01 = New-PSSession -ComputerName Server01
Эта команда создает новый сеанс PSSession на компьютере Server01 и сохраняет его в $ Server01 Переменная.
При создании нескольких объектов PSSession назначьте их переменным с полезными именами.Это будет поможет вам управлять объектами PSSession в последующих командах.
Пример 3: Создание сеансов на нескольких компьютерах
$ s1, $ s2, $ s3 = New-PSSession -ComputerName Server01, Server02, Server03
Эта команда создает три объекта PSSession , по одному на каждом из компьютеров, указанных в ComputerName параметр.
Команда использует оператор присваивания (=) для назначения новых объектов PSSession переменным: $ s1 , $ s2 , $ s3 .Он назначает Server01 PSSession на $ s1 , Server02 PSSession на $ s2 и Server03 PSSession с по $ s3 .
Когда вы назначаете несколько объектов серии переменных, PowerShell присваивает каждому объекту переменная в серии соответственно. Если объектов больше, чем переменных, все остальные объекты присваиваются последней переменной. Если переменных больше, чем объектов, оставшиеся переменные пусты (ноль).
Пример 4: Создание сеанса с указанным портом
New-PSSession -ComputerName Server01 -Port 8081 -UseSSL -ConfigurationName E12
Эта команда создает новый сеанс PSSession на компьютере Server01, который подключается к порту сервера 8081 и использует протокол SSL. Новый PSSession использует альтернативную конфигурацию сеанса, называемую E12.
Перед настройкой порта необходимо настроить прослушиватель WinRM на удаленном компьютере для прослушивания порт 8081.Для получения дополнительной информации см. Описание параметра Порт .
Пример 5: Создание сеанса на основе существующего сеанса
New-PSSession -Session $ s -Credential Domain01 \ User01
Эта команда создает сеанс PSSession с теми же свойствами, что и существующий сеанс PSSession . Вы можете используйте этот формат команды, когда ресурсы существующего сеанса PSSession исчерпаны и новый PSSession необходим для разгрузки части спроса.
Команда использует параметр Session из New-PSSession , чтобы указать PSSession , сохраненный в переменная $ s . Для выполнения команды он использует учетные данные пользователя Domain1 \ Admin01.
Пример 6: Создание сеанса с глобальной областью действия в другом домене
$ global: s = New-PSSession -ComputerName Server1.Domain44.Corpnet.Fabrikam.com -Credential Domain01 \ Admin01
В этом примере показано, как создать сеанс PSSession с глобальной областью действия на компьютере в другом домен.
По умолчанию объекты PSSession , созданные в командной строке, создаются с локальной областью и PSSession объекты, созданные в сценарии, имеют область действия сценария.
Чтобы создать сеанс PSSession с глобальной областью действия, создайте новый сеанс PSSession , а затем сохраните PSSession в переменной, которая приводится к глобальной области. В этом случае выполняется приведение переменной $ s в глобальном масштабе.
Команда использует параметр ComputerName для указания удаленного компьютера.Потому что компьютер находится в другом домене, чем учетная запись пользователя, полное имя компьютера указывается вместе с учетными данными пользователя.
Пример 7: Создание сеансов для многих компьютеров
$ rs = Get-Content C: \ Test \ Servers.txt | Новый-PSSession -ThrottleLimit 50
Эта команда создает сеанс PSSession на каждом из 200 компьютеров, перечисленных в файле Servers.txt, и он сохраняет полученный результат PSSession в переменной $ rs .Объекты PSSession имеют предел дроссельной заслонки 50.
Вы можете использовать этот формат команды, когда имена компьютеров хранятся в базе данных, электронной таблице, текстовый файл или другой текстовый конвертируемый формат.
Пример 8: Создание сеанса с использованием URI
$ s = New-PSSession -URI http: // Server01: 91 / NewSession -Credential Domain01 \ User01
Эта команда создает сеанс PSSession на компьютере Server01 и сохраняет его в переменной $ s .Это использует параметр URI для указания транспортного протокола, удаленного компьютера, порта и альтернативная конфигурация сеанса. Он также использует параметр Credential для указания учетной записи пользователя. у которого есть разрешение на создание сеанса на удаленном компьютере.
Пример 9: Запуск фонового задания в наборе сеансов
$ s = New-PSSession -ComputerName (Get-Content Servers.txt) -Credential Domain01 \ Admin01 -ThrottleLimit 16 Invoke-Command -Session $ s -ScriptBlock {Get-Process PowerShell} -AsJob
Эти команды создают набор из объектов PSSession , а затем запускают фоновое задание в каждом из PSSession объекта.
Первая команда создает новый сеанс PSSession на каждом из компьютеров, перечисленных в Servers.txt. файл. Он использует командлет New-PSSession для создания PSSession . Ценность ComputerName параметр - это команда, которая использует командлет Get-Content для получения списка компьютер называет файл Servers.txt.
Команда использует параметр Credential для создания объектов PSSession , которые имеют разрешение администратора домена, и он использует параметр ThrottleLimit для ограничения команда до 16 одновременных подключений.Команда сохраняет объекта PSSession в $ s Переменная.
Вторая команда использует параметр AsJob командлета Invoke-Command для запуска фона. задание, которое запускает команду Get-Process PowerShell в каждом из объектов PSSession в $ s .
Дополнительные сведения о фоновых заданиях PowerShell см. about_Jobs и about_Remote_Jobs.
Пример 10: Создание сеанса для компьютера с использованием его URI
New-PSSession -ConnectionURI https: // management.exchangengelabs.com/Management
Эта команда создает объекты PSSession , которые подключаются к компьютеру, указанному URI вместо имени компьютера.
Пример 11: Создание параметра сеанса
$ so = New-PSSessionOption -SkipCACheck Новый-PSSession -ConnectionUri https://management.exchangelabs.com/Management -SessionOption $ so -Credential Server01 \ Admin01
В этом примере показано, как создать объект параметра сеанса и использовать параметр SessionOption .
Первая команда использует командлет New-PSSessionOption для создания параметра сеанса. Это сохраняет результирующий объект SessionOption в переменной $, поэтому .
Вторая команда использует параметр в новом сеансе. Команда использует командлет New-PSSession для создать новую сессию. Значением параметра SessionOption является объект SessionOption в переменная $, поэтому .
Пример 12: Создание сеанса с использованием SSH
New-PSSession -HostName UserA @ LinuxServer01
В этом примере показано, как создать новый сеанс PSSession с помощью Secure Shell (SSH).Если настроен SSH на удаленном компьютере, чтобы запросить пароли, вы получите запрос пароля. В противном случае вы придется использовать аутентификацию пользователя на основе ключа SSH.
Пример 13: Создайте сеанс с использованием SSH и укажите порт и ключ аутентификации пользователя
New-PSSession -HostName UserA @ LinuxServer01: 22 -KeyFilePath c: \\ userAKey_rsa
В этом примере показано, как создать сеанс PSSession с помощью Secure Shell (SSH). Он использует порт параметр, чтобы указать используемый порт, и параметр KeyFilePath , чтобы указать ключ RSA, используемый для идентифицировать и аутентифицировать пользователя на удаленном компьютере.
Пример 14: Создание нескольких сеансов с использованием SSH
$ sshConnections = @ {HostName = "WinServer1"; UserName = "домен \ userA"; KeyFilePath = "c: \ users \ UserA \ id_rsa"}, @ {HostName = "UserB @ LinuxServer5"; KeyFilePath = "c: \ UserB \\ id_rsa"} New-PSSession -SSHConnection $ sshConnections
В этом примере показано, как создать несколько сеансов с помощью Secure Shell (SSH) и SSHConnection набор параметров. Параметр SSHConnection принимает массив хеш-таблиц, содержат информацию о подключении для каждого сеанса.Обратите внимание, что в этом примере требуется, чтобы цель на удаленных компьютерах SSH настроен для поддержки аутентификации пользователей на основе ключей.
Параметры
-AllowRedirection
Указывает, что этот командлет разрешает перенаправление этого подключения на альтернативный унифицированный ресурс. Идентификатор (URI).
Когда вы используете параметр ConnectionURI , удаленный пункт назначения может вернуть инструкцию на перенаправить на другой URI. По умолчанию PowerShell не перенаправляет подключения, но вы можно использовать этот параметр, чтобы включить перенаправление соединения.
Вы также можете ограничить количество перенаправлений подключения, изменив MaximumConnectionRedirectionCount значение параметра сеанса. Используйте параметр MaximumRedirection командлета New-PSSessionOption или задайте свойство MaximumConnectionRedirectionCount для $ PSSessionOption предпочтительная переменная. Значение по умолчанию - 5.
Тип: SwitchParameter
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный
-ApplicationName
Задает сегмент имени приложения в URI соединения.Используйте этот параметр, чтобы указать имя приложения, если вы не используете параметр ConnectionURI в команде.
Значение по умолчанию - это значение предпочтительной переменной $ PSSessionApplicationName на локальном компьютер. Если эта предпочтительная переменная не определена, значением по умолчанию является WSMAN. Это значение подходит для большинства применений. Для получения дополнительной информации см. about_Preference_Variables.
Служба WinRM использует имя приложения для выбора прослушивателя для обслуживания запроса на подключение.Значение этого параметра должно соответствовать значению свойства URLPrefix прослушивателя на удаленный компьютер.
Тип: Строка
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Истинный
-Аутентификация
Задает механизм, используемый для аутентификации учетных данных пользователя.Допустимые значения для этого параметра:
По умолчанию
Базовый
Credssp
Дайджест
Kerberos
переговоры
NegotiateWithImplicitCredential
Значение по умолчанию - Default.
Подробнее о значениях этого параметра см. Перечисление AuthenticationMechanism.
Осторожно
Проверка подлинности поставщика поддержки безопасности учетных данных (CredSSP), в которой учетные данные пользователя передается на удаленный компьютер для проверки подлинности, предназначен для команд, требующих проверка подлинности более чем на одном ресурсе, например доступ к удаленному сетевому ресурсу.Этот механизм увеличивает риск безопасности удаленной работы. Если удаленный компьютер скомпрометирован, передаваемые ему учетные данные могут использоваться для управления сетевым сеансом.
Тип: AuthenticationMechanism
Допустимые значения: Default, Basic, Negotiate, NegotiateWithImplicitCredential, Credssp, Digest, Kerberos
Имя 9013 903 903 903 903 по умолчанию 903 903 903 903 903 903 по умолчанию 903
Принять ввод конвейера: Ложь
Принимать подстановочные знаки: Ложь
-CertificateThumbprint
Задает сертификат цифрового открытого ключа (X509) учетной записи пользователя, имеющей разрешение на выполнение это действие.Введите отпечаток сертификата сертификата.
Сертификаты используются при аутентификации на основе сертификата клиента. Их можно сопоставить только с локальными учетные записи пользователей; они не работают с учетными записями домена.
Чтобы получить сертификат, используйте команду Get-Item или Get-ChildItem в сертификате PowerShell: водить машину.
Тип: Строка
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный Ложный подстановочный знак
-ComputerName
Задает массив имен компьютеров.Этот командлет создает постоянное соединение ( PSSession ) на указанный компьютер. Если вы введете несколько имен компьютеров, New-PSSession создает несколько объектов PSSession , по одному для каждого компьютера. По умолчанию это локальный компьютер.
Введите имя NetBIOS, IP-адрес или полное доменное имя одного или нескольких удаленных компьютеры. Чтобы указать локальный компьютер, введите имя компьютера, localhost или точку (.). Когда компьютер находится в другом домене, чем пользователь, требуется полное доменное имя.Ты может также передать имя компьютера в кавычках к New-PSSession .
Чтобы использовать IP-адрес в значении параметра ComputerName , команда должна включать Credential параметр. Кроме того, компьютер должен быть настроен для транспорта HTTPS или IP-адреса. адрес удаленного компьютера должен быть включен в список WinRM TrustedHosts на локальном компьютер. Инструкции по добавлению имени компьютера в список TrustedHosts см. В разделе «Как добавить Компьютер в список доверенных хостов »в about_Remote_Troubleshooting.
Чтобы включить локальный компьютер в значение параметра ComputerName , запустите Windows PowerShell с помощью параметра Запуск от имени администратора.
Тип: Строка []
Псевдонимы: Cn
Положение: 0
Истинное значение: Нет
Принимать подстановочные знаки: Ложь
-ConfigurationName
Задает конфигурацию сеанса, которая используется для нового PSSession .
Введите имя конфигурации или полный URI ресурса для конфигурации сеанса. если ты укажите только имя конфигурации, перед ним будет добавлен следующий URI схемы: http://schemas.microsoft.com/PowerShell .
Конфигурация сеанса для сеанса находится на удаленном компьютере. Если указанный сеанс конфигурация не существует на удаленном компьютере, команда не выполняется.
Значение по умолчанию - это значение предпочтительной переменной $ PSSessionConfigurationName на локальном компьютер.Если эта предпочтительная переменная не задана, по умолчанию используется Microsoft.PowerShell. Для большего информацию см. about_Preference_Variables.
Тип: Строка
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Истинный
-ConnectionUri
Задает URI, который определяет конечную точку соединения для сеанса.URI должен быть полностью квалифицированный. Формат этой строки следующий:
<Транспорт>: // <Имя компьютера>: <Порт> / <Имя приложения>
Значение по умолчанию:
http: // localhost: 5985 / WSMAN
Если вы не укажете ConnectionURI , вы можете использовать UseSSL , ComputerName , Port и ApplicationName , чтобы указать значения ConnectionURI .
Допустимые значения для транспортного сегмента URI: HTTP и HTTPS. Если указать подключение URI с транспортным сегментом, но без указания порта, сеанс создается по стандартам порты: 80 для HTTP и 443 для HTTPS. Чтобы использовать порты по умолчанию для удаленного взаимодействия PowerShell, укажите порт 5985 для HTTP или 5986 для HTTPS.
Если конечный компьютер перенаправляет соединение на другой URI, PowerShell предотвращает перенаправление, если вы не используете в команде параметр AllowRedirection .
True
Тип: Uri []
Псевдонимы: URI, CU
Позиция: 0
Значение по умолчанию: Нет
Принимать подстановочные знаки: False
-ContainerId
Задает массив идентификаторов контейнеров. Этот командлет запускает интерактивный сеанс с каждым из указанные контейнеры.Используйте команду docker ps , чтобы получить список идентификаторов контейнеров. Для большего информацию, см. справку по команда docker ps.
Тип: Строка []
Позиция: Именованный
Значение по умолчанию: Нет
Принять конвейерный ввод: Истинный Принять подстановочные символы : Ложь
-Credential
Задает учетную запись пользователя, у которой есть разрешение на выполнение этого действия.По умолчанию это текущий пользователь.
Введите имя пользователя, например User01 или Domain01 \ User01 , или введите объект PSCredential генерируется командлетом Get-Credential . Если вы введете имя пользователя, вам будет предложено ввести пароль.
Учетные данные хранятся в PSCredential объект, а пароль хранится как SecureString.
Тип: PSCredential
Позиция: Именованный
Значение по умолчанию: Текущий пользователь
Принять ввод конвейера: True
-EnableNetworkAccess
Указывает, что этот командлет добавляет интерактивный маркер безопасности в сеансы обратной связи.Интерактивный token позволяет запускать команды в сеансе обратной связи, которые получают данные с других компьютеров. Например, вы можете запустить команду в сеансе, которая копирует файлы XML с удаленного компьютера на локальный компьютер.
Сеанс обратной связи - это сеанс PSSession , который начинается и заканчивается на одном компьютере. Чтобы создать в циклическом сеансе, опустите параметр ComputerName или установите для него значение точка (.), localhost или имя локального компьютера.
По умолчанию этот командлет создает сеансы обратной связи с помощью сетевого токена, который может не предоставлять достаточное разрешение для аутентификации на удаленных компьютерах.
Параметр EnableNetworkAccess действует только в сеансах обратной связи. Если вы используете EnableNetworkAccess при создании сеанса на удаленном компьютере команда выполняется успешно, но параметр игнорируется.
Вы также можете включить удаленный доступ в циклическом сеансе, используя значение CredSSP Authentication параметр, который делегирует учетные данные сеанса другим компьютерам.
Для защиты компьютера от злонамеренного доступа отключенные сеансы обратной связи с интерактивным токены, созданные с помощью параметра EnableNetworkAccess , можно повторно подключить только с компьютера, на котором был создан сеанс.Отключенные сеансы, использующие CredSSP аутентификацию можно переподключить с других компьютеров. Для получения дополнительной информации см. Отключить-PSSession .
Этот параметр появился в PowerShell 3.0.
Тип: SwitchParameter
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный
-HostName
Задает массив имен компьютеров для соединения на основе Secure Shell (SSH).Это похоже на параметр ComputerName, за исключением того, что подключение к удаленному компьютеру осуществляется по SSH а не Windows WinRM.
Этот параметр появился в PowerShell 6.0.
Ложь
Тип: Строка []
Позиция: 0
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный Ложные символы подстановки
-KeyFilePath
Задает путь к ключевому файлу, используемый Secure Shell (SSH) для аутентификации пользователя на удаленном компьютере.
SSH позволяет выполнять аутентификацию пользователя с помощью закрытых / открытых ключей в качестве альтернативы базовым парольная аутентификация. Если удаленный компьютер настроен для аутентификации по ключу, то это Параметр может использоваться для предоставления ключа, который идентифицирует пользователя.
Этот параметр появился в PowerShell 6.0.
Тип: Строка
Псевдонимы: IdentityFilePath
Позиция: Именованный
Значение по умолчанию:
Входное значение по умолчанию: Ложный 903 Принимать подстановочные знаки: Ложь
-Name
Задает понятное имя для PSSession .
Вы можете использовать имя для ссылки на PSSession при использовании других командлетов, таких как Get-PSSession и Enter-PSSession . Имя не обязательно должно быть уникальным для компьютера или текущий сеанс.
Тип: Строка []
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный Ложный подстановочный знак Ложь
-Порт
Задает сетевой порт на удаленном компьютере, который используется для этого подключения.Чтобы подключиться к удаленный компьютер, удаленный компьютер должен прослушивать порт, который использует соединение. В порты по умолчанию - 5985, который является портом WinRM для HTTP, и 5986, который является портом WinRM для HTTPS.
Перед использованием другого порта необходимо настроить прослушиватель WinRM на удаленном компьютере для прослушивания этот порт. Используйте следующие команды для настройки слушателя:
winrm удалить winrm / config / listener? Адрес = * + Транспорт = HTTP
winrm create winrm / config / listener? Address = * + Transport = HTTP @ {Port = "\ "}
Не используйте параметр Порт без необходимости.Настройка порта в команде применяется ко всем компьютеры или сеансы, на которых выполняется команда. Настройка альтернативного порта может помешать команде от работы на всех компьютерах.
Тип: Int32
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный Ложный подстановочный знак Ложный подстановочный знак
-RunAsAdministrator
Указывает, что PSSession работает от имени администратора.
Тип: SwitchParameter
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный
-сессия
Задает массив из объектов PSSession , которые этот командлет использует в качестве модели для нового PSSession .Этот параметр создает новые объекты PSSession , которые имеют те же свойства, что и указано объектов PSSession .
Введите переменную, содержащую объекты PSSession , или команду, которая создает или получает PSSession объекта, например New-PSSession или Get-PSSession .
Результирующие объекты PSSession имеют одинаковое имя компьютера, имя приложения, URI подключения, порт, имя конфигурации, предел дроссельной заслонки и значение Secure Sockets Layer (SSL) в качестве оригиналов, но у них другое отображаемое имя, идентификатор и идентификатор экземпляра (GUID).
Тип: PSSession []
Позиция: 0
Значение по умолчанию: Нет
Принять ввод конвейера: Истинный Принять подстановочные символы: Ложь
-SessionOption
Задает дополнительные параметры сеанса. Введите объект SessionOption , например тот, который вы создать с помощью командлета New-PSSessionOption или хэш-таблицы, в которой ключи являются сеансовыми имена и значения параметров являются значениями параметров сеанса.
Значения по умолчанию для параметров определяются значением предпочтения $ PSSessionOption переменная, если она установлена. В противном случае значения по умолчанию устанавливаются параметрами, установленными в сеансе. конфигурация.
Значения параметров сеанса имеют приоритет над значениями по умолчанию для сеансов, установленных в $ PSSessionOption переменной предпочтения и в конфигурации сеанса. Однако они не принимают приоритет над максимальными значениями, квотами или ограничениями, установленными в конфигурации сеанса.
Описание параметров сеанса, которые включают значения по умолчанию, см. New-PSSessionOption . Для получения информации о предпочтительной переменной $ PSSessionOption см. about_Preference_Variables. Для получения дополнительной информации о конфигурации сеанса, см. about_Session_Configurations.
Тип: PSSessionOption
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный подстановочный знак
Ложный подстановочный знак
-SSH Соединение
Этот параметр принимает массив хэш-таблиц, где каждая хеш-таблица содержит одно или несколько соединений. параметры, необходимые для установления соединения Secure Shell (SSH) (HostName, Port, UserName, KeyFilePath).
Параметры соединения с хэш-таблицей такие же, как определено для набора параметров HostName .
Параметр SSHConnection полезен для создания нескольких сеансов, каждый из которых требует различная информация о подключении.
Этот параметр появился в PowerShell 6.0.
Ложь
Тип: Хеш-таблица []
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный подстановочный знак
-SSHTransport
Указывает, что удаленное соединение установлено с использованием Secure Shell (SSH).
По умолчанию PowerShell использует Windows WinRM для подключения к удаленному компьютеру. Этот переключатель заставляет PowerShell для использования набора параметров HostName для установления удаленного подключения на основе SSH.
Этот параметр появился в PowerShell 6.0.
Тип: SwitchParameter
Допустимые значения: true
Позиция: Именованный
Значение по умолчанию: Нет
Входное значение по умолчанию: Нет
Принимать подстановочные знаки: Ложь
-Подсистема
Задает подсистему SSH, используемую для нового сеанса PSSession .
Указывает подсистему для использования на цели, как определено в sshd_config. Подсистема запускает конкретную версию PowerShell с предопределенными параметрами. Если указанная подсистема не существует на удаленном компьютере, команда не выполняется.
Если этот параметр не используется, по умолчанию используется подсистема powershell.
Тип: Строка
Позиция: Именованный
Значение по умолчанию: PowerShell
Принять конвейерный ввод: True
-Предел газа
Задает максимальное количество одновременных подключений, которые могут быть установлены для выполнения этой команды.Если вы опустите этот параметр или введете значение 0 (ноль), используется значение по умолчанию 32.
Предел газа применяется только к текущей команде, но не к сеансу или компьютеру.
Тип: Int32
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный Ложный подстановочный знак Ложный подстановочный знак
-Имя пользователя
Задает имя пользователя для учетной записи, используемой для создания сеанса на удаленном компьютере.Пользователь Метод проверки подлинности будет зависеть от того, как на удаленном компьютере настроена Secure Shell (SSH).
Если SSH настроен на базовую аутентификацию по паролю, вам будет предложено ввести пользователя пароль.
Если SSH настроен для аутентификации пользователя на основе ключа, то путь к файлу ключа может быть предоставлен через KeyFilePath, и запрос пароля не появится. Обратите внимание, что если файл ключей пользователя клиента расположен в известном месте SSH, то параметр KeyFilePath не требуется для аутентификация, и аутентификация пользователя будет происходить автоматически на основе имени пользователя.См. SSH документацию по аутентификации пользователя на основе ключа для получения дополнительной информации.
Это необязательный параметр. Если параметр UserName не указан, то текущий пользователь, вошедший в систему имя используется для соединения.
Этот параметр появился в PowerShell 6.0.
Тип: Строка
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложные Ложные символы подстановки
-UseSSL
Указывает, что этот командлет использует протокол SSL для установления соединения с удаленным компьютером.По умолчанию SSL не используется.
WS-Management шифрует весь контент PowerShell, передаваемый по сети. UseSSL параметр предлагает дополнительную защиту, которая отправляет данные через HTTPS-соединение вместо HTTP-соединение.
Если вы используете этот параметр, но SSL недоступен на порту, который используется для команды, команда не работает.
Тип: SwitchParameter
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный
-Используйте WindowsPowerShell
{{Заполните описание UseWindowsPowerShell}}
Тип: SwitchParameter
Позиция: Именованный
Значение по умолчанию: Нет
Принять ввод конвейера: Ложный
-VMId
Задает массив идентификаторов виртуальных машин.Этот командлет запускает интерактивный сеанс с каждым из указанные виртуальные машины. Чтобы увидеть доступные вам виртуальные машины, используйте следующая команда:
Get-VM | Select-Object -Property Name, ID
Тип: Guid []
Псевдонимы: VMGuid
Позиция: 0
Истинное значение: Нет Входное значение по умолчанию: Нет
Принимать подстановочные знаки: Ложь
-VMName
Задает массив имен виртуальных машин.Этот командлет запускает интерактивный сеанс с каждым указанных виртуальных машин. Чтобы увидеть доступные вам виртуальные машины, используйте Get-VM командлет.
Тип: Строка []
Позиция: Именованный
Значение по умолчанию: Нет
Принять конвейерный ввод: Истинный Принять подстановочные символы : Ложь
Входы
Система.Строка, System.URI, System.Management.Automation.Runspaces.PSSession
Вы можете передать этому командлету строку, URI или объект сеанса.
Выходы
PSSession
Банкноты
Этот командлет использует инфраструктуру удаленного взаимодействия PowerShell. Чтобы использовать этот командлет, локальный компьютер и все удаленные компьютеры должны быть настроены для удаленного взаимодействия PowerShell. Для большего информацию см. about_Remote_Requirements.
Чтобы создать сеанс PSSession на локальном компьютере, запустите PowerShell с запуском от имени администратора. вариант.
Когда вы закончите с PSSession , используйте командлет Remove-PSSession , чтобы удалить PSSession и освободите его ресурсы.
Наборы параметров HostName и SSHConnection были включены, начиная с PowerShell 6.0. Они были добавлены для обеспечения удаленного взаимодействия PowerShell на основе Secure Shell (SSH). И SSH, и PowerShell поддерживается на нескольких платформах (Windows, Linux, macOS) и удаленное взаимодействие PowerShell. будет работать на этих платформах, где установлены и настроены PowerShell и SSH.Это отдельно от предыдущей Windows только удаленное взаимодействие, основанное на WinRM и большей части WinRM особые функции и ограничения не применяются. Например, квоты на основе WinRM, параметры сеанса, настраиваемая конфигурация конечной точки и функции отключения / повторного подключения в настоящее время не поддерживаются. За Дополнительные сведения о настройке удаленного взаимодействия PowerShell SSH см. в Удаленное взаимодействие PowerShell через SSH.
Как запустить сценарий PowerShell на удаленном компьютере? - TheITBros
Функциональность удаленного выполнения команд в PowerShell называется PowerShell Remoting (появилась в PowerShell 2.0) и на основе возможностей протокола Web Services for Management (WS-Management). С помощью PowerShell Remoting вы можете запускать команды на одном или нескольких удаленных компьютерах. Вы можете использовать режим интерактивного сеанса с удаленными компьютерами, временное или постоянное соединение. Ранее мы рассказали, как запустить сценарий PowerShell из планировщика заданий. В этой статье мы рассмотрим несколько примеров удаленного выполнения сценария PowerShell.
Настройка WinRM для удаленного взаимодействия PowerShell
Для удаленного подключения к компьютеру через PowerShell на нем должна быть включена и настроена WinRM (служба удаленного управления Windows) (по умолчанию она отключена).Связь между компьютерами осуществляется по протоколам HTTP или HTTPS, и весь сетевой трафик между компьютерами зашифрован. Вы можете использовать NTLM и Kerberos для аутентификации на удаленном компьютере.
Чтобы проверить состояние службы WinRM, выполните команду Get-service:
get-service winrm
Как видите, служба WS-Management запущена.
Если служба WinRM не запущена, необходимо включить ее на удаленном компьютере с помощью команды:
Enable-PSRemoting
Эта команда подготавливает компьютер к удаленному управлению: запускает службу WinRM, изменяет тип запуска на Автоматический , и добавляет необходимые исключения в брандмауэр Защитника Windows.
Подсказка . PowerShell Remoting использует TCP-порты HTTP (5985) и HTTPS (5986) для сетевых подключений.
Если удаленный компьютер находится в рабочей группе (не присоединен к домену Active Directory) и к нему применен профиль сети Public (вместо домена или частного), вам необходимо явно разрешить входящий трафик WinRM в Windows Брандмауэр:
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
Чтобы проверить соединение с удаленным сервером через WinRM, используйте следующую команду:
Test-WSMan server1
Если вы получили ответ, значит, удаленный компьютер доступен через PowerShell Remoting.
Подсказка . Если вы подключаетесь к удаленному компьютеру через PS Remoting по IP-адресу, вы можете получить сообщение об ошибке:
Не удалось подключиться к удаленному серверу 192.168.1.70 со следующим сообщением об ошибке: Клиент WinRM не может обработать запрос. Аутентификация по умолчанию может использоваться с IP-адресом при следующих условиях: транспортный протокол HTTPS или место назначения находится в списке TrustedHosts, и предоставляются явные учетные данные.
В этом случае вам необходимо установить сертификат HTTPS для PowerShell Remoting на удаленном компьютере (долгий путь) или добавить этот хост к доверенным на вашем управляющем компьютере:
Set-Item wsman: \ localhost \ Client \ TrustedHosts -значение 192.168.1.70
Выполнение удаленных команд с помощью PowerShell Remoting
Чтобы интерактивно подключиться к удаленному компьютеру (с именем хоста Server1) через PowerShell, выполните следующую команду:
Enter-PSSession Server1
Вид PowerShell CLI изменится. В начале строки будет имя удаленного компьютера, к которому вы подключены через WinRM. После установления удаленного сеанса все команды, вводимые в консоли PowerShell, выполняются на удаленном компьютере.PS Remoting работает следующим образом: команды, введенные на локальном компьютере, передаются на удаленный компьютер и выполняются там, затем результат передается обратно. Поскольку все команды выполняются локально, можно не беспокоиться о совместимости с версией и модулями PoSh.
Чтобы завершить удаленный интерактивный сеанс, выполните команду:
Exit-PSSession
На удаленных компьютерах в интерактивном режиме обычно выполняются только простые задачи управления.Чтобы выполнить сложную команду или запустить сценарий PowerShell удаленно, используйте командлет Invoke-Command.
Использование Invoke-Command для удаленного запуска сценариев PowerShell
Следующая команда создаст удаленное соединение с компьютером Server1 и запустит блок команд, указанный в параметре ScriptBlock . После этого удаленный сеанс автоматически закроется.
Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName server1
Вы можете запустить задачу в фоновом режиме, запустив Invoke-Command с параметром -AsJob .Но в этом случае команда не вернет результат в консоль PoSh. Чтобы получить подробную информацию о фоновом задании, используйте командлет Receive-Job .
PowerShell позволяет запускать локальные сценарии PS1 на удаленных компьютерах. Идея состоит в том, что вы храните все инструкции PowerShell в локальном файле .PS1 на вашем компьютере. С помощью PowerShell Remoting вы можете передать файл PS1 на удаленный компьютер и выполнить его там.
Для этого используйте параметр -FilePath в командлете Invoke-Command вместо -ScriptBlock .Например, чтобы запустить сценарий c: \ ps \ tune.ps1 на трех удаленных серверах, вы можете использовать следующую команду:
Invoke-Command -FilePath c: \ ps \ tune.ps1 -ComputerName server1, server2, server3
Основное преимущество этого способа запуска сценариев PowerShell заключается в том, что вам не нужно копировать файл сценария PS1 на удаленные компьютеры. Вы можете использовать не только локальный сценарий, но и сценарий PS в общей сетевой папке, к которой можно получить доступ с локального компьютера.
Если вам нужно запускать сценарии PowerShell с учетными данными, отличными от текущего пользователя, вам нужно использовать параметр Credential.
Во-первых, вам необходимо получить учетные данные и сохранить их в переменной:
$ cred = Get-Credential
Теперь вы можете запустить сценарий PS на удаленных компьютерах с сохраненными разрешениями на учетные данные.
Invoke-Command -FilePath c: \ ps \ tune.ps1 -ComputerName server1, server2, server3 -Credential $ cred
Вы можете сохранить список компьютеров в текстовом файле и запустить сценарий PowerShell удаленно на всех компьютерах одновременно:
Invoke-command -comp (get-content c: \ ps \ servers.txt) -filepath c: \ ps \ tune.ps1
По умолчанию командлет Invoke-Command отправляет сценарий PS1 на 32 удаленных компьютера из списка одновременно. Если компьютеров больше 32, то PoSh проверяет состояние выполнения скрипта на первых 32 компьютерах. Если сценарий завершен, команда выполняется на следующем компьютере. С помощью параметра ThrottleLimit вы можете увеличить этот предел, но будьте осторожны, чтобы не перегрузить вашу сеть.
Использование постоянных подключений PowerShell (сеансов)
Каждый раз, когда вы запускаете Invoke-Command, с удаленным компьютером создается новый сеанс.Это требует времени и системных ресурсов. В PowerShell вы можете создать один сеанс и выполнять в нем все команды и сценарии.
Используя командлет New-PSSession , вы можете создавать постоянные сеансы PowerShell с удаленными компьютерами.
Например, давайте создадим сеансы с тремя компьютерами и сохраним их в переменной $ PSSess:
Invoke-Command -FilePath c: \ ps \ tune.ps1 -ComputerName server1, server2, server3 $ PSSess = New-PSSession -ComputerName server1, server2, server3
После установления сеанса вы можете запустить его для выполнения команд и сценариев.Поскольку сеансы постоянны, вы можете получать от них данные и использовать их в других командах и скриптах.
Например, следующая команда получит список процессов на удаленных серверах и сохранит их в переменной $ RemoteProcesses :
Invoke-Command -Session $ PSSess {$ RemoteProcesses = Get-Process}
Теперь вы можете используйте эту переменную в других командах в тех же сеансах. В следующем примере мы используем командлет Where-Object для поиска процессов, которые используют более 500 МБ ОЗУ):
Invoke-Command -Session $ PSSess {$ RemoteProcesses | где-объект {$ _.WorkingSet -GT 500000 * 1024} | выберите имя процесса, @ {l = "Рабочая память (МБ)"; e = {$ _. workingset / 1mb}} | sort "Working Memory (MB)" -Descending}
Постоянный удаленный сеанс PowerShell будет оставаться активным, пока вы не закроете консоль PowerShell или не закроете принудительно или не удалите сеанс с помощью командлеты Disconnect-PSSession или Remove-PSSession соответственно.
Как видите, PowerShell предоставляет широкие возможности для запуска сценариев и команд на удаленных компьютерах.Администраторы Windows, несомненно, могут использовать PowerShell Remoting в дополнение к классическому инструменту PsExec от Sysinternals.
Мне нравятся технологии и разработка веб-сайтов. С 2012 года я веду несколько собственных веб-сайтов и делюсь полезным контентом о гаджетах, администрировании ПК и продвижении веб-сайтов.
Последние сообщения Кирилла Кардашевского (посмотреть все) Как управлять своими серверами удаленно с помощью PowerShell Серверы Windows, удаленное управление и сценарии: что все это связывает вместе? Powershell.Вы можете использовать PowerShell для управления локальным и удаленным компьютерами. Используя WinRM (удаленное управление Windows), вы можете настроить все свои серверы и рабочие станции на прием удаленных подключений PowerShell от авторизованных пользователей, чтобы ими можно было управлять из командной строки удаленно, вручную или с помощью сценария. Это значительно расширяет возможности PowerShell и позволяет отказаться от сценариев WMI для управления системами. По умолчанию удаленное управление на ваших серверах отключено.Вы можете включить его вручную или централизованно. Здесь мы рассмотрим оба метода. Включение удаленного управления Если вы хотите включить удаленное управление одним сервером: Откройте административную командную строку PowerShell Выполните следующую команду Enable-PSRemoting –Force [ввод] Это пройдет и запустите службу WinRM, установите для нее тип запуска «Автоматический», создайте прослушиватель на всех сетевых интерфейсах / ip.addrs для подключений удаленного управления и настройте брандмауэр Windows на прием этих подключений.Это простая кнопка для удаленного управления. Использование объекта групповой политики, чтобы упростить задачу Это достаточно просто для одного сервера, но вы, вероятно, не захотите входить в систему на каждом сервере в домене, чтобы сделать это. К счастью, в этом нет необходимости. Вы можете использовать объект групповой политики (GPO), чтобы сделать то же самое: Запустите консоль управления групповой политикой. Создайте новый объект групповой политики (или отредактируйте существующий объект групповой политики, если вы хотите добавить эти параметры к тому, что у вас уже есть.Просто не редактируйте для этого политику домена по умолчанию). Просмотрите дерево групповой политики, чтобы перейти к конфигурации компьютера, политикам, административным шаблонам, компонентам Windows, удаленному управлению Windows (WinRM), службе WinRM. Установите как минимум следующее: - Разрешить удаленное управление сервером через WinRM в положение «Включено». Вышеупомянутые будут использовать настройки по умолчанию, которые включают только аутентификацию Kerberos и Negotiate, а также прослушиватель TCP 5985. Вы также можете настроить: - Разрешить базовую аутентификацию на Включено (для базовой аутентификации через SSL) - Включить Совместимость HTTP-прослушивателя для включения -Включите совместимость HTTPS-прослушивателя для включения. Подключение к удаленной системе Чтобы подключиться к другой системе в вашем домене, выполните следующие действия. Это предполагает, что и ваша рабочая станция, и сервер присоединены к домену, и ваша учетная запись имеет права администратора на сервере. Если вам нужно предоставить другие учетные данные, включите необязательную часть в скобки, чтобы вам было предложено ввести пароль. Откройте административную командную строку PowerShell на своем ПК. Введите следующую команду: Enter-PSSession –ComputerName host [-Credential username ] Вот и все. Вы даже можете использовать PowerShell для управления своими Linux-компьютерами! Есть модуль PowerShell для управления Linux. Что ж, на самом деле это модуль, который позволяет вам устанавливать SSH-подключения к любому SSH-прослушивателю из сеанса PowerShell, но если вы пишете сценарий, который должен воздействовать как на Windows, так и на Linux в одном сценарии, возможность использовать этот модуль для встраивания сеанса SSH в хост Linux и выполнения команд действительно классный! Проверить это. No related posts.