Приемы работы с удаленными системами через PowerShell
Я часто работаю с командами на удаленных системах через PowerShell как во время пентестов, так и при решении повседневных задач. Запуска удаленных команд происходит через протокол WinRM (Windows Remote Management), который, насколько мне известно, поддерживается в Windows Vista SP 1, Windows 7, Windows Server 2008 и Windows Server 2012.
Автор: Scott Sutherland
Я часто работаю с командами на удаленных системах через PowerShell как во время пентестов, так и при решении повседневных задач. Запуска удаленных команд происходит через протокол WinRM (Windows Remote Management), который, насколько мне известно, поддерживается в Windows Vista SP 1, Windows 7, Windows Server 2008 и Windows Server 2012.
Первоначальные настройки
Перед тем как начать работу с удаленной системой, необходимо выполнить настройку.
1. Запустите консоль PowerShell от имени администратора и выполните следующую команду:
Команда выше разрешает запуск команд на удаленных системах. Если у вас возникли проблемы, используйте команды ниже:
2. Убедитесь в том, что служба WinRM запускается автоматически.
# Устанавливаем нужный режим
Set-Service WinRM -StartMode Automatic
# Проверяем, что служба запущена
Get-WmiObject -Class win32_service | Where-Object
3. Устанавливаем у всех хостов статус «достоверный» (можно сделать позже).
# Доверяем всем хостам
Set-Item WSMan:localhost\client\trustedhosts -value *
# Проверяем настройку достоверных хостов
Примеры работы с удаленными системами
Перед ознакомлением с примерами рекомендую вам прочитать прекрасную статью, посвященную работе с удаленными командами в PowerShell.
Запуск одиночной команды на удаленной системе
Команда "Invoke-Command" предназначена для запуска команд на удаленных системах. Можно работать от имени текущего пользователя, либо использовать стороннюю учетную запись, если вы работаете в системе, которая не является частью домена:
Invoke-Command –ComputerName MyServer1 -ScriptBlock
Invoke-Command –ComputerName MyServer1 -Credentials demo\serveradmin -ScriptBlock
Если установлен модуль для работы с ActiveDirectory, становится возможным запуск команд на множестве систем при помощи каналов (pipeline):
Иногда на удаленной системе требуется запустить скрипт, хранящийся локально:
Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1
Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1 -Credentials demo\serveradmin
Если вы генерируете команды или функции динамически, которые затем передаются на удаленную систему можно использовать связку команд invoke-expression и invoke-command:
$MyCommand = "hostname"
$MyFunction = "function evil
invoke-command -ComputerName MyServer1 -Credentials demo\serveradmin -ScriptBlock
Организация интерактивной консоли на удаленной системе
Организовать интерактивную консоль в PowerShell на удаленной системе можно при помощи команды "Enter-PsSession" (немного похожа на SSH). Команда "Enter-PsSession" также запускается либо от имени текущего пользователя, либо при помощи альтернативной учетной записи:
Enter-PsSession –ComputerName server1.domain.com
Enter-PsSession –ComputerName server1.domain.com –Credentials domain\serveradmin
Закрытие сессии выполняется при помощи команды "Exit-PsSession":
Создание фоновых сессий
Еще одна полезная возможность позволяет создавать фоновые сессии (команда "New-PsSession"). Фоновые сессии могут оказаться полезны при запуске множества команд во множестве систем. Как и предыдущие команды, команда "New-PsSession" запускается от имени текущего пользователя, либо при помощи альтернативной учетной записи:
New-PSSession -ComputerName server1.domain.com
New-PSSession –ComputerName server1.domain.com –Credentials domain\serveradmin
Если установлен модуль для работы с ActiveDirectory, становится возможным единовременное создание фоновых сессий для множества систем (этот трюк можно выполнить различными способами). Ниже показан пример создания фоновых сессий для всех систем, входящих в домен. В примере создание сессий происходит в системе, не входящей в домен, при помощи альтернативной учетной записи домена.
New-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "
" -Server a.b.c.d -credential domain\user
cd RemoteADS:
Get-ADComputer -Filter * -Properties name | select @
| New-PSSession
Вывод перечня фоновых сессий
Как только создано несколько фоновых сессий, можно просмотреть их перечень при помощи команды "Get-PsSession".
Взаимодействие с фоновыми сессиями
Первое время у меня было ощущение схожее с тем, как я работал с сессиями в MetaSploit. Однако фоновые сессии в PowerShell чуть более стабильны. Ниже показан пример взаимодействия при помощи идентификатора сессии:
Enter-PsSession –id 3
Для выхода из сессии используйте команду "Exit-PsSession". Сессия перейдет обратно в фоновый режим.
Запуск команд через фоновые сессии
Если вы хотите выполнить команду во всех активных сессиях, используйте связку команд "Invoke-Command" и "Get-PsSession".
Invoke-Command -Session (Get-PSSession) -ScriptBlock
Удаление фоновых сессий
Для удаления всех активных сессий используйте команду "Disconnect-PsSession"
Удаленные команды в 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
Эта команда откроет удаленную сессию на SRV4, выполнит блок команд, указанный в параметре -ScriptBlock , и закроет сессию. А чтобы задание выполнялось в фоновом режиме, дополнительно можно указать параметр -AsJob .
Cледует помнить о том, что при работе в фоновом режиме PowerShell не возвращает результат. Для его получения придется воспользоваться командлетом Receive-Job .
Для того, чтобы выполнить не пару-тройку команд, а какой либо скрипт, у Invoke-Command есть параметр –FilePath , который можно использовать вместо –ScriptBlock для определения файла сценария. Для примера я создал скрипт, который выводит список остановленных служб и запустил его на удаленной машине SRV4:
Invoke-Command -FilePath .\script.ps1 -ComputerName SRV4
Управление «один ко многим»
Довольно часть возникает необходимость параллельно выполнить одну задачу на нескольких компьютерах. Это довольно легко можно сделать с помощью того же Invoke-Command . Например, имена компьютеров можно просто перечислить через запятую:
Invoke-Command -ScriptBlock
Поместить в переменную:
$servers = @(″SRV1″,″SRV2″,″SRV3″)
Invoke-Command -ScriptBlock
Или взять из файла:
Invoke-Command -ScriptBlock
(Get-Content .\servers.txt)
Примечание: у Invoke-Command есть параметр ThrottleLimit , ограничивающий максимальное количество компьютеров, которыми можно управлять одновременно. По умолчанию этот параметр равен 32. При необходимости его можно изменить, но учтите, что повышение этого параметра увеличит нагрузку на процессор и память вашего компьютера, поэтому эту операцию нужно выполнять с большой осторожностью.
Сессии
Каждый раз при выполнении Invoke-Command создается новая сессия, на создание которой тратится время и ресурсы. Чтобы этого избежать мы можем открыть одну сессию, в которой и выполнять все команды. Например, откроем сессию с именем SRV4 на компьютер SRV4 и поместим ее в переменную $session, а затем этой сессии выполним нашу задачу (остановим многострадальный spooler):
$session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock
-Session $session
Сессия будет активна до того момента, пока мы не выйдем из консоли PowerShell. Также сессию можно закрыть — Disconnect-PSSession или удалить — Remove-PSSession .
А теперь несколько интересных возможностей, появившихся в PowerShell 3.0. Если раньше при выходе из сессии или закрытии консоли сессия удалялась, то в PS 3.0 при закрытии сессия переходит в состояние disconnected. Мы можем открыть новый сеанс на этом же (или любом другом) компьютере и выполнить команду прямо в этой отключенной сессии. В качестве примера стартуем на компьютере SRV4 сервис печати, остановленный в прошлый раз:
Invoke-Command -ScriptBlock
-ComputerName SRV4 -Disconnected
Еще один вариант использования отключенных сессий — запуск длительных по времени задач. Для примера откроем сессию c именем LongJob на SRV4 и запустим в ней фоновое задание, которое будет выводить список сервисов с интервалом в 1 минуту:
$session = New-PSSession -ComputerName SRV4 -Name LongJob
Invoke-Command -Session $session -ScriptBlock`
Посмотрим, как выполняется задача и закроем сессию:
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
Затем экспортируем из удаленной сессии командлеты Active Directory и помещаем их в локальный модуль RemoteAD:
Export-PSSession -Session $session -CommandName *-AD* -OutputModule RemoteAD`
-AllowClobber
Эта команда создаст в папке WindowsPowerShell\Modules\RemoteAD новый модуль PowerShell. Загружены будут только командлеты с именами, соответствующими шаблону *-AD*. При этом сами командлеты не копируются на локальный компьютер. Локальный модуль служит своего рода ярлыком, а сами команды будут выполняться на удаленном контроллере домена.
После создания модуля удаленную сессию можно закрыть, она больше не понадобится.
Импортируем новый модуль в текущий сеанс (в PS 3.0 можно этот шаг пропустить):
А теперь внимание — мы не открываем удаленную сессию с контроллером домена, где расположены командлеты. Не нужно явно запускать этот сеанс — это можно сделать неявно, попытавшись выполнить удаленные командлеты:
New-ADUser -Name BillGates -Company Microsoft
Get-ADUser BillGates
При этом будет восстановлено удаленное подключение к контроллеру домена, после чего команда будет передана на контроллер домена и там выполнена. Результат выполнения будет сериализован в XML и передан по сети на локальный компьютер, где будет выполнена десериализация в объекты, с которыми может работать PowerShell.
Удаленный сеанс будет активным до тех пор, пока вы не закроете консоль или не удалите модуль RemoteAD.
Неявное удаленное управление позволяет работать с командлетами на удаленном компьютере практически так же, как если бы они были установлены на локальной машине. При этом все необходимые командлеты всегда под рукой, что довольно удобно.
В заключение скажу, что на данный момент PowerShell Remoting является основным инструментом для удаленного управления операционными системами Windows. Поэтому знать о его возможностях и уметь ими пользоваться просто необходимо любому Windows-администратору.
Что такое Windows PowerShell и с чем его едят? Часть 6: Решение практических задач
В предыдущих статьях мы разобрались с основами среды и достаточно подробно изучили язык программирования Microsoft PowerShell. Завершая цикл, мы рассмотрим работу с процессами и службами, реестром и журналами событий в распределенной среде, а также разберем некоторые способы администрирования операционной системы, настройки стороннего ПО и просмотра сведений об установленном оборудовании. Для этого в PowerShell активно применяются объекты различных типов, изучению которых были посвящены четвертая и пятая части цикла.
Оглавление:
Удаленное управление
PowerShell позволяет удаленно управлять одним или несколькими компьютерами. Для этого можно задействовать объекты .NET, CIM, WMI, поддерживающие соответствующую функцию командлеты, удаленный запуск команд или интерактивную удаленную сессию. Подключение осуществляется через PS remoting/WinRM по протоколу HTTP (порт 5985) или HTTPS (порт 5986, требуется сертификат SSL). По умолчанию соединение устанавливается по HTTP, но данные все равно шифруются с использованием симметричного ключа AES-256. Поддерживаются два способа аутентификации: NTLM и Kerberos (по умолчанию). Второй способ доступен, если удаленный компьютер входит в домен AD, а в Workgroup или если вместо доменного имени указан IP, применяется NTLM и требуется дополнительная настройка. На компьютере, к которому мы подключаемся, должен быть запущен сервис WinRM.
Если сервис не запущен, можно воспользоваться командлетом Enable-PSRemoting. Виртуальные машины RuVDS с Windows Server Core конфигурируются с настроенным из коробки удаленным доступом и никаких дополнительных действий не требуют. Для использования HTTP также придется добавить хост, к которому необходимо подключиться, в TrustedHost компьютера, с которого запускается команда. Если машина работает в глобальной сети, может потребоваться настройка брендмауэра. PS remoting/WinRM позволяет создавать удаленные сессии (New-PSSession, Get-PSSession, Enter-PSSession), выполнять команды и скрипты (Invoke-Command) на одном или нескольких компьютерах, а также использовать командлеты с параметром -ComputerName. Последнее справедливо и в отношении командлетов для работы с CIM/WMI. Более подробная информация доступна на сайте Microsoft.
Командлеты vs CIM/WMI
Хотя некоторые командлеты поддерживают параметр -ComputerName, возможности их применения для работы с хостами в сети ограничены. Создания сессий и удаленного выполнения команд PowerShell хватает не всегда, и тут нам помогут командлеты для работы с WMI или CIM (иногда можно обойтись и NET-объектами). Использование CIM предпочтительнее, поскольку дальнейшая разработка и поддержка WMI в Windows прекращена. В обоих случаях используется Common Information Model (CIM) и экземпляры соответствующих классов. При необходимости можно просматривать структуру результирующих объектов, фильтровать, сортировать и выделять их из коллекции, а также проводить другие действия над полученными результатами. При работе в интерактивном режиме текстовый вывод несложно отформатировать, а в скриптах обычно обращаются к свойствам и методам объектов. Хотя командлеты WMI и CIM похожи, в первом случае нетрудно получить ссылку на конкретный объект (экземпляр класса) и непосредственно вызвать один из его методов без использования Invoke-WmiMethod. Результирующие CIM-объекты методов класса не содержат, поэтому вызывать командлет Invoke-CimMethod для управления придется обязательно.
Управление процессами через CIM/WMI
В предыдущих статьях мы довольно часто использовали Get-Process, который возвращает соответствующие запущенным в системе процессам объекты типа System.Diagnostics.Process. С помощью этого командлета можно получать сведения только о локальном компьютере, а чтобы работать с удаленной машиной, нам снова понадобятся командлеты CIM/WMI и класс Win32_Process. Приведем примеры используемых для работы с ним команд.
Предыдущие примеры иллюстрируют получение информации о запущенных на локальной машине процессах, для работы с удаленными компьютерами используется параметр -ComputerName:
Управление службами через CIM/WMI
Командлет Get-Service в актуальных реализациях поддерживает параметр -ComputerName, но позволяет только получить информацию о статусе сервиса на удаленной машине — управлять им через свойства и методы результирующих объектов не получится. Более правильным в распределенной среде подходом также считается использование командлетов CIM и WMI. Как и для процессов, для служб в объектной модели CIM имеется специальный класс Win32_Service.
Чтобы работать с удаленным компьютером, необходимо воспользоваться параметром -ComputerName:
Для уточняющих запросов используется параметр -Filter. Таким способом несложно выяснить, стартует служба автоматически или должна быть запущена вручную:
Аналогичным образом можно сгруппировать службы по учетной записи:
Следующая команда возвращает все сервисы, запущенные от имени администратора:
Для командлетов CIM фильтры работают аналогично:
Для реальной работы важен не столько текстовый вывод командлетов, сколько сами бинарные объекты. С их помощью можно запускать и останавливать соответствующие службы, менять режим их запуска или устанавливать свойства. В случае с WMI методы объектов вызываются напрямую или через Invoke-WmiMethod. Для объектов CIM доступно только использование Invoke-CimMethod.
Работа с реестром
Системный реестр Windows — это имеющая древовидную структуру иерархическая база данных, содержащая информацию об аппаратной и программной конфигурации компьютера. Каждый ее узел — это содержащий другие узлы (записи базы данных) раздел либо имеющий некое значение ключ. Раздел может содержать вложенные подразделы: по структуре реестр напоминает файловую систему и для работы с ним в PowerShell есть виртуальные «диски». Просмотреть их можно с помощью командлета Get-PSDrive, а обратиться к соответствующему разделу — с помощью Set-Location (псевдоним cd).
«Диски» реестра содержат «каталоги» (разделы), подкаталоги «подразделы» и «файлы» (параметры). Для просмотра подразделов используется командлет Get-ChildItem (псевдоним dir), а для просмотра параметров: Get-ItemProperty. Разделы реестра представлены экземплярами .NET-класса Microsoft.Win32.RegistryKey, а параметры — System.Management.Automation.PSCustomObject. Чтобы получить доступ к системному реестру удаленной машины, придется напрямую использовать объекты .NET, WMI или CIM.
Работа с журналами событий
Журналы событий (Event logs) в Windows — важный для администратора инструмент, с помощью которого можно отслеживать состояние системы и приложений, а также оперативно анализировать возникающие проблемы. Обычно для работы нужны журнал безопасности (Security log), системный журнал (System log) и журнал приложений (Application log). В зависимости от установленных компонентов и настроенных ролей, на сервере могут быть и другие: журнал службы каталога (Directory service log), журнал службы каталога (Directory service log) или, например, журнал службы репликации файлов (File Replication Service log). Для их просмотра на локальной машине используется консоль управления MMC, а в PowerShell командлет Get-EventLog. Для работы с удаленными хостами можно воспользоваться соответствующими определенным журналам объектами CIM и WMI (экземплярами класса Win32_NTEventlogFile).
Пример иллюстрирует работу с локальными журналами, для подключения к удаленному компьютеру нужен параметр -ComputerName:
Информация об ОС и оборудовании
С помощью командлетов CIM и WMI можно получать разнообразную информацию от работающих в сети компьютеров, а также управлять ими. Для этих целей применяются командлеты CIM/WMI и соответствующие классы. Рассмотрим их использование на практических примерах.
Класс Win32_OperatingSystem решает множество разнообразных задач. С помощью его метода Win32Shutdown завершается сеанс пользователя:
Для получения информации о BIOS потребуется класс Win32_BIOS
Вывод свойств операционной системы:
Класс Win32_QuickFixEngineering предназначен для получения списка установленных обновлений:
Завершая цикл публикаций, мы хотим напомнить, что PowerShell — нечто большее, чем просто командная оболочка. Скорее она напоминает гибрид Bash и SSH/SSHD с возможностью использования объектов .NET и объектной модели CIM. Это позволяет решать сложные задачи управления распределенной ИТ-средой, хотя и требует иногда громоздких синтаксических конструкций. Без знания PowerShell сегодня не обойдется ни один грамотный системный администратор Windows.
Enter-PSSession: интерактивное управление удаленным компьютером из PowerShell
04.08.2021
itpro
PowerShell, Windows 10, Windows Server 2016, Windows Server 2019
комментариев 8
Командлет Enter-PSSession позволяет создать постоянную интерактивную PowerShell сессию с удаленным компьютером. Все команды, которые вы вводите в вашей командной строке, выполняются на удаленном компьютере. В этой статье мы рассмотрим основные возможности и особенности использования командлета Enter-PSSession для удаленного управления компьютерами с Windows 10 и Windows Server 2019/2016.
Для подключения в самом простом случае нужно указать только имя компьютера (параметр ComputerName). Чтобы подключиться к удаленному компьютеру, достаточно выполнить команду:
Если у текущего пользователя есть полномочия на подключение к удаленному серверу, вы подключитесь к удаленному компьютеру.
Можно перед подключением запросить учетные записи пользователя:
Enter-PsSession –ComputerName hq-srv01.contoso.com –Credentials contoso\kbuldogov
$creds = Get-Credential
Enter-PSSession -ComputerName hq-srv01 -Credential $creds
Обратите внимание, что в начале командной строки PowerShell теперь в квадратных скобках указывается имя удаленного компьютера ( [hq-srv01.contoso.com] ). Это позволяет понять, работаете ли вы в локальной сессии или в удаленной.
В вашей консоли отображаются результаты всех команд, выполненных удаленно. Можно выполнить команду hostname и убедится, что вы выполнили команду на удаленном компьютере.
В этой интерактивной командной строке вы можете выполнять любые команды (в соответствии со своими полномочиями).
Можно изменить настройки DNS на удаленном компьютере:
Set-DNSClientServerAddress –InterfaceIndex 6 –ServerAddresses 192.168.13.4, 192.168.100.4
Чтобы завершить интерактивную сессию удаленного управления, нужно выполнить команду Exit-PSSession или exit. Строка-приглашение PS примет свой обычный вид, и вы вернетесь к своей локальной PowerShell консоли:
В Windows Server 2016/2019 PowerShell Remoting включен по умолчанию (это видно в консоли Server Manager -> Local Server -> Remote Management = Enabled).
В десктопных версиях Windows (Win10, Win11) PSRemoting и служба WinRM отключены.
Вы можете проверить, включен ли PSremoting на текущем компьютере:
Данная команда также позволяет получить список пользователей и групп, которым разрешено подключаться через WinRM. Для использования PSRemoting учетная запись пользователя должна состоять в группе Administrators или Remote Management Users . Особенности удаленного использования WinRM без прав администратора описаны здесь.
Вы можете протестировать, можно ли подключится через PowerShell Remoting к вашему компьютеру локально:
Test-WSMan -ComputerName localhost
Если команда вернет версию схемы WSMan, значит удаленные подключения к этому компьютеру через PS Remoting разрешены.
Если PowerShell Remoting отключен или не настроен, появился ошибка:
Чтобы включить PowerShell Remoting, выполните команду:
- Включает службу WinRM и настраивает ее на автозапуск;
- Создает точку подключения на стандартном порту WinRM (TCP/5985 для HTTP трафика);
- Добавляет исключения в Windows Firewall для WS-Management (если вы настраиваете PSRemoting вручную, добавьте правило самостоятельно);
- Разрешает удаленные PowerShell сессии;
- Перезапускает службу WinRM.
Убедитесь, что служба WinRM запущена и настроена на автоматический запуск:
Get-Service WinRM | Select MachineName,Name,Status, StartType
Enable-PSRemoting -SkipNetworkProfileCheck -Force
В домене Active Directory проще всего настроить Windows Remote Management (PSRemoting) на серверах и компьютера централизованно с помощью групповой политики.
В новых версиях PowerShell(v6 и v7) поддерживается использование протокола Secure Shell (SSH) для подключения к удаленному компьютеру через PowerShell Remoting. На удаленном компьютере должен быть доступна точка подключения SSH (в Windows теперь есть встроенный SSH сервер). Вы можете запустить интерактивную сессию PSRemoting поверх SSH с помощью команды:
Enter-PSSession -HostName [email protected]:22 -KeyFilePath c:\PS\your_rsa_key
Enter-PSSession можно использовать совместно с командой New-PSSession:
$s = New-PSSession -ComputerName hq-srv01.contoso.com
Enter-PSSession -Session $s
Enter-PSSession поддерживает несколько способов аутентификации. Вы можете задать нужный способ с помощью параметра -Authentication . Поддерживаются Basic, Digest, Kerberos, CredSSP, NegotiateWithImplicitCredential, Negotiate Challenge.
В примере выше мы показали пример интерактивного подключения Enter-PSSession между компьютерами в одном домене Windows (для подключения достаточно указать FQDN или короткое имя, используется Kerberos аутентфикация). Если попробовать подключиться к удаленному компьютеру по IP адресу или CNAME, аутентификация не пройдет:
Для подключения к удаленному компьютеру по IP можно добавить этот хост в список доверенных (Trusted Hosts) или использовать SSL (более безопасно).
Чтобы добавить IP адрес в доверенные, выполните команду:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 192.168.13.5
Можно добавить в доверенные хосты по маске
Set-Item WSMan:\localhost\Client\TrustedHosts -Value *.winitpro.ru
Вывести список доверенных хостов:
Аналогично нужно добавить ваш хост в доверенные на удаленном компьютере.
Чтобы подключиться к удаленному компьютеру по IP адресу, используйте такую команду:
Enter-PSSession -ComputerName 192.168.13.5 -Credential (Get-Credential -UserName contoso\kbuldogov)
Командлеты Enter-PSSession и New-PSSession создают постоянную сессию типа один к одному и используются в основном в интерактивных сценариях. Если вам нужно автоматизация, или есть задачи, которые нужно выполнить сразу на множестве удаленных компьютерах, используйте командлет Invoke-Command.
Предыдущая статья Следующая статья 