Удаленное управление powershell: Удаленное взаимодействие PowerShell — PowerShell

Как в Powershell подключиться к удаленному компьютеру

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


  • WMI

  • CIM

  • PS remoting/WinRM

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



Enter-PSSession -ComputerName CL1


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



ssh CL1


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



Invoke-Command -ComputerName AD,CL1 -ScriptBlock {Get-ComputerInfo}


Где:

-ComputerName — имена компьютеров (или одного)

-Scriptblock — скрипт или командлет в скобках {}


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



ssh root@192. 168.1.1 'ifconfig'


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


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


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



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


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



Enable-PSRemoting


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


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



Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any


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



Invoke-Command -ComputerName 192.168.3.100 -ScriptBlock {Get-Command}


Получим ошибку:

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


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



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


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



$cred = Get-Credential
Invoke-Command -ComputerName 192.168.3.134 -ScriptBlock {Get-ComputerInfo} -Credential $cred


Где:

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

-Credential — сюда мы передаем переменную


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


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



New-PSSession -ComputerName 192.168.3.134 -Credential $cred


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



Get-PSSession


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



Enter-PSSession -Id 9


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



$cred = Get-Credential
$s = New-PSSession -ComputerName 192. 168.3.134 -Credential $cred
Invoke-Command -Session $s -FilePath c:\scripts\test.ps1


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



Test-Connection -Source CL1,CL2 -ComputerName AD -Credential $cred


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


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



Get-Help Enter-PSSession -Examples
Get-Command -Noun PSSession


или по powershell invoke



Get-Help Invoke-Command -Examples


 

…

Рекомендую

Подписывайтесь на наш Telegram канал

Теги:

#powershell

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

Существует довольно много методов для работы с удаленными компьютерами. Есть Windows Management Instrumentation (WMI), широко используемый в VBScript. Есть различные утилиты, которые позволяют осуществлять удаленное управление, типа PSExec от  Sysinternals. Даже многие командлеты PowerShell имеют параметр ComputerName для выполнения на удаленных компьютерах.

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

PowerShell Remoting решает большинство описанных проблем. Он основан на Microsoft реализации протокола Web Services for Management (WS-Management), а для связи использует службу  Windows Remote Management (WinRM). Связь между компьютерами осуществляется по HTTP (по умолчанию) или HTTPS. Весь трафик между двумя компьютерами шифруется на уровне протокола (за исключением случаев, когда используется SSL).  Поддерживаются несколько методов аутентификации, включая NTLM и Kerberos.

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

Есть несколько способов управления с помощью PowerShell Remoting.

Управление «один к одному»

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

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

Посмотрим состояние сервиса и закроем удаленную сессию:

Get-Service -Name spooler
Exit-PSSession

 

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

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName SRV4

Эта команда откроет удаленную сессию на SRV4, выполнит блок команд, указанный в параметре -ScriptBlock, и закроет сессию. А чтобы задание выполнялось в фоновом режиме, дополнительно можно указать параметр -AsJob.

 

Cледует помнить о том, что при работе в фоновом режиме PowerShell не возвращает результат. Для его получения придется воспользоваться командлетом Receive-Job.

 

Для того, чтобы выполнить не пару-тройку команд, а какой либо скрипт, у Invoke-Command есть параметр –FilePath, который можно использовать вместо –ScriptBlock для определения файла сценария. Для примера я создал скрипт, который выводит список остановленных служб и запустил его на удаленной машине SRV4:

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

Управление «один ко многим»

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

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName SRV4,SRV5

Поместить в переменную:

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

Или взять из файла:

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

 

Примечание: у Invoke-Command есть параметр ThrottleLimit, ограничивающий максимальное количество компьютеров, которыми можно управлять одновременно. По умолчанию этот параметр равен 32. При необходимости его можно изменить, но учтите, что повышение этого параметра увеличит нагрузку на процессор и память вашего компьютера, поэтому эту операцию нужно выполнять с большой осторожностью.

Сессии

Каждый раз при выполнении Invoke-Command создается новая сессия, на создание которой тратится время и ресурсы. Чтобы этого избежать мы можем открыть одну сессию, в которой и выполнять все команды. Например, откроем сессию с именем SRV4 на компьютер SRV4 и поместим ее в переменную $session, а затем этой сессии выполним нашу задачу (остановим многострадальный spooler):

$session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock {Get-Service spooler | Stop-Service}`
-Session $session

Сессия будет активна до того момента, пока мы  не выйдем из консоли PowerShell. Также сессию можно закрыть — Disconnect-PSSession или удалить — Remove-PSSession.

 

А теперь несколько интересных возможностей, появившихся в PowerShell 3.0. Если раньше при выходе из сессии или закрытии консоли сессия удалялась, то в PS 3.0 при закрытии сессия переходит в состояние disconnected. Мы можем открыть новый сеанс на этом же (или любом другом) компьютере и выполнить команду прямо в этой отключенной сессии. В качестве примера стартуем на компьютере SRV4 сервис печати, остановленный в прошлый раз:

Invoke-Command -ScriptBlock {Start-Service spooler}`
-ComputerName SRV4 -Disconnected

 

Еще один вариант использования отключенных сессий — запуск длительных по времени задач. Для примера откроем сессию c именем LongJob на SRV4 и запустим в ней фоновое задание, которое будет выводить список сервисов с интервалом в 1 минуту:

$session = New-PSSession -ComputerName SRV4 -Name LongJob
Invoke-Command -Session $session -ScriptBlock`
{Get-Service | foreach {$_;sleep 60} } -AsJob

Посмотрим, как выполняется задача и закроем сессию:

Receive-Job -Name Job2
Disconnect-PSSession $session

 

Идем на другой компьютер и открываем консоль, Подключаемся к сессии LongJob и с помощью командлета Receive-PSSession получаем результат выполнения задания:

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

 

Или еще вариант, без явного подключения к сессии с помощью Connect-PSSession:

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

 

Примечание: для того, чтобы результат остался в системе, Receive-Job надо использовать с параметром -Keep.

Неявное удаленное управление

Еще один, довольно нестандартный способ удаленного управления — неявное удаленное управление (Implicit remoting). Используя его можно, не создавая удаленной сессии, локально выполнять командлеты, находящиеся на удаленном компьютере.

Для примера берем обычную рабочую станцию, без установленных средств удаленного администрирования. Создаем удаленную сессию с контроллером домена SRV4 и импортируем в эту сессию модуль Active Directory:

$session = New-PSSession -ComputerName SRV4
Invoke-Command {Import-Module ActiveDirectory} -Session $session

Затем экспортируем из удаленной сессии командлеты Active Directory и помещаем их в локальный модуль RemoteAD:

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

Эта команда создаст в папке WindowsPowerShell\Modules\RemoteAD новый модуль PowerShell. Загружены будут только командлеты с именами, соответствующими шаблону *-AD*. При этом сами командлеты не копируются на локальный компьютер. Локальный модуль служит своего рода ярлыком, а сами команды будут выполняться на удаленном контроллере домена.

После создания модуля удаленную сессию можно закрыть, она больше не понадобится.

 

Импортируем новый модуль в текущий сеанс (в PS 3.0 можно этот шаг пропустить):

Import-Module RemoteAD

А теперь внимание — мы не открываем удаленную сессию с контроллером домена, где расположены командлеты. Не нужно явно запускать этот сеанс — это можно сделать неявно, попытавшись выполнить удаленные командлеты:

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

При этом будет восстановлено удаленное подключение к контроллеру домена, после чего команда будет передана на контроллер домена и там выполнена. Результат выполнения будет сериализован в XML и передан по сети на локальный компьютер, где будет выполнена десериализация в объекты, с которыми может работать PowerShell.

Удаленный сеанс будет активным до тех пор, пока вы не закроете консоль или не удалите модуль RemoteAD.

 

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

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

об удаленных требованиях — PowerShell

  • Статья
  • 8 минут на чтение

Краткое описание

Описывает системные требования и требования к конфигурации для работы
удаленные команды в PowerShell.

Подробное описание

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

Примечание

Многие командлеты (включая Get-Service , Get-Process , Get-WMIObject ,
Командлеты Get-EventLog и Get-WinEvent ) получают объекты с удаленных компьютеров
с помощью методов Microsoft .NET Framework для извлечения объектов. Они делают
не использовать инфраструктуру удаленного взаимодействия PowerShell. Требования в этом
document не применяются к этим командлетам.

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

Системные требования

Для запуска удаленных сеансов в Windows PowerShell 3.0 локальные и удаленные компьютеры
должен иметь следующее:

  • Windows PowerShell 3.0 или более поздней версии
  • Microsoft .NET Framework 4 или более поздней версии
  • Удаленное управление Windows 3. 0

Для запуска удаленных сеансов в Windows PowerShell 2.0 локальный и удаленный
компьютеры должны иметь следующее:

  • Windows PowerShell 2.0 или более поздней версии
  • Microsoft .NET Framework 2.0 или более поздней версии
  • Удаленное управление Windows 2.0

Вы можете создавать удаленные сеансы между компьютерами под управлением Windows PowerShell
2.0 и Windows PowerShell 3.0. Однако функции, работающие только в Windows
PowerShell 3.0, например возможность отключения и повторного подключения к сеансам,
доступны только в том случае, если на обоих компьютерах установлена ​​Windows PowerShell 3.0.

Чтобы найти номер версии установленной версии PowerShell,
используйте автоматическую переменную $PSVersionTable .

Удаленное управление Windows (WinRM) 3.0 и Microsoft .NET Framework 4
включены в Windows 8, Windows Server 2012 и более новые выпуски Windows
Операционная система. WinRM 3.0 входит в состав Windows Management Framework 3. 0.
для старых операционных систем. Если на компьютере нет необходимого
версию WinRM или Microsoft .NET Framework, установка завершается ошибкой.

Полномочия пользователя

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

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

Дескрипторы безопасности в конфигурациях сеанса по умолчанию,
Microsoft. PowerShell , Microsoft.PowerShell32 и
Microsoft.PowerShell.Workflow , разрешить доступ только членам
Группа администраторов .

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

Члены группы Администраторы на компьютере могут определить, кто
разрешение удаленного подключения к компьютеру путем изменения безопасности
дескрипторы в конфигурациях сеанса по умолчанию и путем создания нового сеанса
конфигурации с разными дескрипторами безопасности.

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

Сетевые расположения Windows

Начиная с Windows PowerShell 3. 0, Enable-PSRemoting 9Командлет 0026 может включить
удаленное взаимодействие на клиентских и серверных версиях Windows на частных, доменных и
общедоступные сети.

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

В клиентских версиях Windows с частными и доменными сетями по умолчанию
командлет Enable-PSRemoting создает правила брандмауэра, разрешающие неограниченное
удаленный доступ.

Чтобы включить удаленное взаимодействие в клиентских версиях Windows с общедоступными сетями, используйте
Параметр SkipNetworkProfileCheck командлета Enable-PSRemoting . Это создает
правило брандмауэра, разрешающее удаленный доступ только с компьютеров,
локальная подсеть.

Чтобы снять ограничение локальной подсети в общедоступных сетях и разрешить удаленное
доступ из всех расположений в клиентских и серверных версиях Windows, используйте
Командлет Set-NetFirewallRule в модуле NetSecurity . Запустите следующее
команда:

 Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Любой

Примечание

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

В Windows PowerShell 2.0, в серверных версиях Windows Enable-PSRemoting
создает правила брандмауэра, разрешающие удаленный доступ во всех сетях.

В Windows PowerShell 2. 0, в клиентских версиях Windows, Enable-PSRemoting
создает правила брандмауэра только в частных и доменных сетях. Если сеть
место общедоступное, Ошибка Enable-PSRemoting .

Запуск от имени администратора

Права администратора необходимы для следующих операций удаленного взаимодействия:

  • Установление удаленного подключения к локальному компьютеру. Это обычно
    известный как «петлевой» сценарий.

  • Управление конфигурациями сеансов на локальном компьютере.

  • Просмотр и изменение настроек WS-Management на локальном компьютере. Это
    настройки в узле LocalHost диска WSMAN:.

Для выполнения этих задач необходимо запустить PowerShell с параметром «Запуск от имени».
администратор», даже если вы являетесь членом группы «Администраторы » на
локальный компьютер.

В Windows 7 и Windows Server 2008 R2 для запуска PowerShell с
параметр Запуск от имени администратора :

  1. Нажмите кнопку Пуск, щелкните Все программы, щелкните Стандартные, а затем щелкните
    папку PowerShell.
  2. Щелкните правой кнопкой мыши PowerShell и выберите 9.0037 Запуск от имени администратора .

Чтобы запустить Windows PowerShell с параметром Запуск от имени администратора :

  1. Нажмите кнопку Пуск, щелкните Все программы, а затем
    папка.
  2. Щелкните правой кнопкой мыши PowerShell и выберите Запуск от имени администратора .

Параметр Запуск от имени администратора также доступен в других проводниках Windows.
записи для PowerShell, включая ярлыки. Просто щелкните правой кнопкой мыши
пункт, а затем нажмите Запуск от имени администратора .

При запуске PowerShell из другой программы, например Cmd.exe, используйте
параметр Запуск от имени администратора для запуска программы.

Как настроить компьютер для удаленного взаимодействия

Компьютеры, работающие под управлением всех поддерживаемых версий Windows, могут устанавливать удаленное
подключения и запускать удаленные команды в PowerShell без каких-либо
конфигурация. Однако, чтобы получать подключения и разрешать пользователям создавать
локальные и удаленные сеансы PowerShell, управляемые пользователями ("PSSessions") и
запускать команды на локальном компьютере, необходимо включить PowerShell
удаленное взаимодействие на компьютере.

Windows Server 2012 и более новые версии Windows Server включены для
Удаленное взаимодействие PowerShell по умолчанию. Если настройки изменены, вы можете
восстановить настройки по умолчанию, запустив командлет Enable-PSRemoting .

Во всех других поддерживаемых версиях Windows необходимо запустить
Командлет Enable-PSRemoting для включения удаленного взаимодействия PowerShell.

Функции удаленного взаимодействия PowerShell поддерживаются WinRM
служба, которая является реализацией Microsoft веб-служб для
Протокол управления (WS-Management). Когда вы включаете PowerShell
удаленного взаимодействия, вы меняете стандартную конфигурацию WS-Management и добавляете систему
конфигурация, позволяющая пользователям подключаться к WS-Management.

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

  1. Запустите PowerShell с параметром Запуск от имени администратора .
  2. В командной строке введите: Enable-PSRemoting

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

 Новый-PSSession

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

 Идентификатор Имя Имя_компьютера Состояние Имя_конфигурации
-- ---- ------------ ----- -----
1 Session1 localhost Открыт Microsoft.PowerShell

Если команда не удалась, для получения помощи см.
about_Remote_Troubleshooting.

Понимание политик

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

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

Ограничения базовой аутентификации в Linux и macOS

При подключении из системы Linux или macOS к Windows базовая аутентификация
через HTTP не поддерживается. Обычную аутентификацию можно использовать по протоколу HTTPS.
установка сертификата на целевой сервер. Сертификат должен иметь
Имя CN, совпадающее с именем хоста, не просрочено и не отозвано. Самоподписанный
Сертификат может быть использован для целей тестирования.

См. Как настроить WINRM для HTTPS
для получения дополнительной информации.

Следующая команда, запускаемая из командной строки с повышенными привилегиями, настроит
Прослушиватель HTTPS в Windows с установленным сертификатом.

 $hostinfo = '@{Hostname=""; CertificateThumbprint=""}'
winrm создать winrm/config/Listener?Address=*+Transport=HTTPS $hostinfo

На стороне Linux или macOS выберите Basic для проверки подлинности и -UseSSl.

Примечание

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

 # Указанный локальный пользователь должен иметь права администратора на целевой машине.
# Укажите неполное имя пользователя.
$cred = имя пользователя Get-Credential
$session = New-PSSession -Computer  -Credential $cred `
  -Базовая аутентификация -UseSSL

Альтернативой Basic Authentication по HTTPS является Переговоры . Этот
приводит к проверке подлинности NTLM между клиентом и сервером, а полезная нагрузка
шифруется через HTTP.

Ниже показано использование Negotiate with New-PSSession :

 # Указанный пользователь должен иметь права администратора на целевой машине.
$cred = Get-Credential username@hostname
$session = New-PSSession -Computer  -Credential $cred `
  -Аутентификация переговоров

Примечание

Windows Server требует дополнительного параметра реестра для включения
администраторы, кроме встроенного администратора, для подключения с помощью NTLM.
Обратитесь к Параметр реестра LocalAccountTokenFilterPolicy в разделе
Negotiate Аутентификация в Authentication for Remote Connections

См. также

  • about_Remote
  • about_Remote_Variables
  • about_PSSessions
  • Вызов команды
  • Enter-PSSession
  • Новый-PSSession

Удаленное взаимодействие PowerShell через SSH — PowerShell

  • Статья
  • 7 минут на чтение

Обзор

Удаленное взаимодействие PowerShell обычно использует WinRM для согласования подключения и передачи данных. SSH сейчас
доступен для платформ Linux и Windows и обеспечивает настоящую многоплатформенную удаленную работу PowerShell.

WinRM предоставляет надежную модель размещения для удаленных сеансов PowerShell. Удаленное взаимодействие на основе SSH не
в настоящее время поддерживают настройку удаленных конечных точек и Just Enough Administration (JEA).

Удаленное взаимодействие SSH позволяет выполнять базовое удаленное взаимодействие сеансов PowerShell между компьютерами Windows и Linux. SSH
удаленное взаимодействие создает хост-процесс PowerShell на целевом компьютере в качестве подсистемы SSH. В конце концов
мы реализуем общую модель хостинга, аналогичную WinRM, для поддержки конфигурации конечной точки и
ЮА.

Командлеты 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 сборки 1809 и Windows Server 2019. Дополнительные сведения см.
Управляйте Windows с помощью OpenSSH. Для Linux установите SSH, включая сервер sshd, это подходит
для вашей платформы. Вам также необходимо установить PowerShell с GitHub, чтобы получить функцию удаленного взаимодействия SSH.
Сервер SSH должен быть настроен для создания подсистемы SSH для размещения процесса PowerShell на
удаленный компьютер. И вы должны включить пароль или аутентификация на основе ключа .

Установите службу SSH на компьютер с Windows

  1. Установите последнюю версию PowerShell. Для получения дополнительной информации см.
    Установка PowerShell в Windows.

    Вы можете подтвердить, что PowerShell поддерживает удаленное взаимодействие SSH, указав параметр New-PSSession .
    наборы. Вы заметите, что имена наборов параметров начинаются с SSH . Эти наборы параметров
    включить SSH параметры.

     (Get-Command New-PSSession).ParameterSets.Name
 
     Имя
----
SSHHost
SSHHostHashParam

  2. Установите последнюю версию Win32 OpenSSH. Инструкции по установке см.
    Начало работы с OpenSSH.

    Примечание

    Если вы хотите установить PowerShell в качестве оболочки по умолчанию для OpenSSH, см.
    Настройка Windows для OpenSSH.

  3. Отредактируйте файл sshd_config , расположенный по адресу $env:ProgramData\ssh .

    Убедитесь, что включена аутентификация по паролю:

     Аутентификация по паролю да

    Создайте подсистему SSH, в которой размещается процесс PowerShell на удаленном компьютере:

     Подсистема powershell c:/progra~1/powershell/7/pwsh. exe -sshs -nologo

    Примечание

    Начиная с PowerShell 7.4, вам больше не нужно использовать параметр -nlogo при запуске
    PowerShell в режиме сервера SSH.

    Примечание

    Расположение исполняемого файла PowerShell по умолчанию — c:/progra~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"' |
  Select-Object EightDotThreeFileName
 
    ---------------------
c:\программа~1

    При необходимости включите аутентификацию по ключу:

     PubkeyAuthentication да

    Дополнительные сведения см. в разделе Управление ключами OpenSSH.

  4. Перезапустите службу sshd .

     Перезапуск службы sshd

  5. Добавьте путь, по которому установлен OpenSSH, в переменную среды Path. Например,
    C:\Program Files\OpenSSH\ . Эта запись позволяет найти ssh.exe .

Установите службу SSH на компьютер Ubuntu Linux

  1. Установите последнюю версию PowerShell, см. Установка PowerShell в Ubuntu.

  2. Установите сервер Ubuntu OpenSSH.

     sudo apt установить openssh-клиент
sudo apt установить openssh-сервер

  3. Отредактируйте файл sshd_config в расположении /etc/ssh .

    Убедитесь, что включена аутентификация по паролю:

     Аутентификация по паролю да

    При необходимости включите аутентификацию по ключу:

     PubkeyAuthentication да

    Для получения дополнительной информации о создании ключей SSH в Ubuntu см. справочную страницу для
    ssh-кейген.

    Добавьте запись подсистемы PowerShell:

     Подсистема powershell /usr/bin/pwsh -sshs -nlogo

    Примечание

    Расположение исполняемого файла PowerShell по умолчанию — /usr/bin/pwsh . Местоположение может варьироваться
    в зависимости от того, как вы установили PowerShell.

    Примечание

    Начиная с PowerShell 7.4, вам больше не нужно использовать параметр -nlogo при запуске
    PowerShell в режиме сервера SSH.

  4. Перезапустите службу ssh .

     sudo systemctl перезапустить sshd.service

Установите службу SSH на компьютер с macOS

  1. Установите последнюю версию PowerShell. Для дополнительной информации,
    Установка PowerShell на macOS.

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

    1. Открыть Системные настройки .
    2. Нажмите Общее
    3. Нажмите Совместное использование .
    4. Отметьте Удаленный вход в систему , чтобы установить Удаленный вход в систему: Включено .
    5. Разрешить доступ соответствующим пользователям.

  2. Отредактируйте файл sshd_config по адресу /private/etc/ssh/sshd_config .

    Используйте текстовый редактор, например nano :

     судо нано /private/etc/ssh/sshd_config

    Убедитесь, что включена аутентификация по паролю:

     Аутентификация по паролю да

    Добавьте запись подсистемы PowerShell:

     Подсистема powershell /usr/local/bin/pwsh -sshs -nlogo

    Примечание

    Расположение исполняемого файла PowerShell по умолчанию — /usr/local/bin/pwsh . Местоположение может
    зависит от того, как вы установили PowerShell.

    Примечание

    Начиная с PowerShell 7.4, вам больше не нужно использовать параметр -nlogo при запуске
    PowerShell в режиме сервера SSH.

    При необходимости включите аутентификацию по ключу:

     PubkeyAuthentication да

  3. Перезапустите службу sshd .

     sudo launchctl остановить com.openssh.sshd
sudo launchctl запустить 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:
 
 $сеанс
 
 Идентификатор Имя ComputerName ComputerType Состояние ConfigurationName Доступность
 -- ---- ------------ ------------ ----- --------------- -- ------------
  1 SSh2 UbuntuVM1 RemoteMachine Открыта DefaultShell Доступна
 
 Enter-PSSession $сессия
 
 [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) CPU(s) Id SI ProcessName PSComputerName
------- ------ ----- ----- ------ -- -- ----------- ------ --------
      0 0 0 193.23 10635 635 powershell UbuntuVM1
      0 0 0 21 4,92 11033 017 powershell UbuntuVM1
      0 0 0 20 3.07 11076 076 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:
 
 $сеанс
 
 Идентификатор Имя ComputerName ComputerType Состояние 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
CLRверсия
PSВерсия 6.0.0-альфа
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
GitCommitId v6.0.0-альфа.17
[WinVM2]: PS C:\Users\PSRemoteUser\Documents>

Ограничения

  • Команда sudo не работает в удаленном сеансе с компьютером Linux.

  • PSRemoting через SSH не поддерживает профили и не имеет доступа к $PROFILE . Однажды в
    сеанс, вы можете загрузить профиль, указав полный путь к файлу. это не
    связанные с профилями SSH. Вы можете настроить сервер SSH для использования PowerShell в качестве оболочки по умолчанию.
    и загрузить профиль через SSH. Дополнительную информацию см. в документации по SSH.

  • До PowerShell 7.1 удаленное взаимодействие через SSH не поддерживало удаленные сеансы второго перехода. Этот
    возможность была ограничена сеансами с использованием WinRM. PowerShell 7.1 позволяет использовать Enter-PSSession и
    Enter-PSHostProcess для работы из любого интерактивного удаленного сеанса.