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

Для проверки службы или выполнения одинаковой команды на нескольких Windows-компьютерах не всегда нужен графический рабочий стол. PowerShell Remoting позволяет открыть удалённую командную сессию либо отправить блок команд и получить результат. Ниже — авторский учебный маршрут для двух подконтрольных Windows-машин в локальной сети. Рассматриваем транспорт WinRM, а не отдельный вариант remoting через SSH.

Наша цель — проверить связь и выполнить безобидную команду, сохранив понятные границы доступа. Имя сервера SERVER01 и имя домена CONTOSO условные: замените их своими. Настройку принимающей машины выполняйте локально или через уже имеющийся административный канал; не рассчитывайте включить ещё не работающий remoting через него самого.

Выбрать оболочку и проверить исходное состояние

Windows PowerShell 5.1 и PowerShell 7 могут стоять рядом. Важно, из какой оболочки вы включаете приём и к какой конфигурации затем подключаетесь. Выполните на принимающем компьютере:

$PSVersionTable
Get-Service WinRM
Test-WSMan localhost

В таблице версий найдите PSVersion и PSEdition. Команда Get-Service показывает состояние службы, а Test-WSMan обращается к WS-Management. Ошибка последней до настройки ещё не объясняет, что именно отсутствует: служба, listener или доступ. Зафиксируйте исходный результат и переходите к настройке выбранной среды.

Включение remoting в PowerShell 7 создаёт и включает endpoint соответствующей установки; оно не заменяет включение endpoint Windows PowerShell. Если нужен именно Windows PowerShell, запускать Enable-PSRemoting следует из него. Если нужен PowerShell 7, после настройки посмотрите фактическое имя его endpoint, а не угадывайте его по версии оболочки на клиенте.

Что меняет Enable-PSRemoting

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

Enable-PSRemoting
Get-PSSessionConfiguration
Get-ChildItem WSMan:\localhost\Listener
Test-WSMan localhost

Команда настройки запускает WinRM, задаёт автоматический запуск, создаёт listener, настраивает исключение брандмауэра и конфигурации сессий. Это изменение конфигурации компьютера, а не только проверка. Оно нужно там, где принимают удалённые команды; на машине, которая только отправляет их, само по себе включение приёма не требуется.

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

Сохраните имя нужной session configuration из вывода. Например, имя PowerShell.7 может присутствовать для соответствующей установки; используйте именно имеющееся на вашем хосте. Успешный Test-WSMan подтверждает ответ службы, но ещё не доказывает, что конкретной учётной записи разрешён доступ к нужному PowerShell endpoint.

Проверить подключение в домене

На административном клиенте начните с имени сервера. В доменной среде имя важно: подключение по IP меняет условия аутентификации и не является универсальным обходом ошибок DNS. В примере выбрана конфигурация Microsoft.PowerShell для Windows PowerShell; для другого endpoint замените значение после проверки на сервере.

Test-WSMan SERVER01
$remoteCredential = Get-Credential 'CONTOSO\AdminUser'
Enter-PSSession -ComputerName SERVER01 -ConfigurationName Microsoft.PowerShell -Credential $remoteCredential
Get-Culture
Exit-PSSession

После Enter-PSSession команды вводятся в удалённой интерактивной сессии. Exit-PSSession возвращает в локальную оболочку. Это удобно для последовательной проверки одного компьютера. Для отдельной команды можно не входить интерактивно:

Invoke-Command -ComputerName SERVER01 -ConfigurationName Microsoft.PowerShell -Credential $remoteCredential -ScriptBlock {
    Get-Culture
}

С ComputerName такая операция использует временное соединение. Если следующие команды должны использовать сохранённые в удалённой сессии переменные и функции, изучите New-PSSession и передачу Session: новый независимый Invoke-Command не обещает сохранить рабочее состояние предыдущего. RDP остаётся другим инструментом — для работы с графическими приложениями, а не обязательной предпосылкой этих команд.

Вне домена: HTTPS и точечный TrustedHosts

В домене при подключении по имени обычно используется Kerberos, позволяющий проверить стороны. В workgroup либо при обращении по IP условия иные: NTLM не даёт той же гарантии личности сервера. Microsoft описывает HTTPS с проверкой сертификата или настройку TrustedHosts на клиенте. Последняя означает разрешение использовать соответствующий сценарий подключения, а не доказательство благонадёжности компьютера.

Для HTTPS на принимающей машине заранее настраивается HTTPS listener и подходящий сертификат, которому доверяет клиент и имя которого соответствует серверу. Один параметр UseSSL не создаёт listener и не выпускает сертификат. Пример подключения к уже настроенному серверу:

$remoteCredential = Get-Credential 'SERVER01\AdminUser'
Enter-PSSession -ComputerName SERVER01 -UseSSL -ConfigurationName Microsoft.PowerShell -Credential $remoteCredential

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

Get-Item WSMan:\localhost\Client\TrustedHosts
$trustedBefore = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'SERVER01' -Concatenate
Get-Item WSMan:\localhost\Client\TrustedHosts

В примере добавляется одно проверенное имя, а не *. Перед изменением убедитесь, что оно ещё не присутствует и что выбранный способ соответствует вашей политике. TrustedHosts хранится в клиентской конфигурации WinRM и не является персональным разрешением только текущего пользователя. Список не выдаёт учётной записи права на сервере.

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

Защита — не только буквы HTTPS

По документации Microsoft, после исходной аутентификации WinRM шифрует PowerShell remoting communication как при HTTP, так и при HTTPS. Поэтому фраза «HTTP всегда передаёт все команды открытым текстом» некорректна. При этом нужно отдельно решать проверку личности сервера и условия исходной аутентификации: именно здесь нельзя приравнивать TrustedHosts к сертификату или Kerberos.

Обычные конечные точки по умолчанию доступны администраторам. Права операционной системы продолжают действовать в удалённой сессии. Для ограниченного доступа рассматривают права конкретной session configuration и специализированные конфигурации, а не раздачу полного администрирования всем пользователям. Изменение security descriptor — отдельная административная работа; заранее установите, кому и для каких действий нужен доступ.

При Access denied сначала выясните, какой пользователь, какой endpoint и какие права реально участвуют в запросе. Не подменяйте проверку прав расширением сетевого доступа. Для подключения вне Kerberos задавайте Credential явно, в том числе при намерении использовать ту же учётную запись: это отдельное условие такого сценария.

Диагностика: двигаться от связи к правам

Наблюдение	Следующая проверка
Не отвечает Test-WSMan	Имя и маршрут, служба WinRM, listener и применимые правила брандмауэра
Служба отвечает, но сессия не открывается	Имя конфигурации, учётная запись и разрешение подключения
Ошибка аутентификации вне домена	HTTPS и сертификат либо согласованный точечный TrustedHosts, явные credentials
Подключились, но доступен не тот PowerShell	ConfigurationName и версия удалённой среды через $PSVersionTable
Отдельная операция запрещена	Права пользователя на конкретный объект, а не только факт успешного входа

Для поиска следов откройте Event Viewer и журналы Applications and Services Logs. Исследование Mandiant описывает WinRM Operational как источник сведений о входящих и исходящих remoting-соединениях. Для PowerShell 7 официальная документация указывает журнал PowerShellCore/Operational; при включённом Script Block Logging там записываются события 4104. Журналы Windows PowerShell и PowerShell 7 нужно различать, а не искать любую команду в первом попавшемся канале.

Полное содержимое script blocks не появляется автоматически от одного Enable-PSRemoting: необходима соответствующая настройка журналирования, а в Windows — регистрация провайдера событий. Сопоставляйте время, имя пользователя, источник, endpoint и текст ошибки. Доступность событий зависит от настроек и сохранности журнала; пустой поиск не доказывает отсутствия подключения. Содержимое команд может включать чувствительные данные, поэтому права на журналы и защищённое журналирование также входят в задачу администрирования.

Рабочий итог этого упражнения — известная версия принимающего endpoint, успешная безобидная удалённая команда и зафиксированные изменения WinRM. Только после этого переносите подход на реальные административные задачи с конкретными правами и сетевыми ограничениями.