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

Обновлено: 04.07.2024

Я не могу подключиться к удаленному серверу с помощью enter-pssession -computername serverA . Мой сценарий:

Я пытаюсь enter-pssession -computername serverA под учетными данными администратора домена от serverB до serverA, и он выдает следующую ошибку:

когда я пытаюсь enter-pssession -computername serverB под учетными данными администратора домена от сервера, он отлично работает! Он также работает, если я использую localhost так: enter-pssession -computername localhost под учетными данными администратора домена (на сервере) также работает, но когда я пробую имя хоста на сервере (вместо localhost) enter-pssession -computername serverA Он выдает ту же ошибку.

Я также пытался использовать get-credential и предоставить различные типы учетных данных, но это не помогло. Единственное, что помогло, это использование локальной (не доменной) учетной записи администратора и запуск enter-pssession -computername serverA -credentials $cred и это работал, но только локально, я смог сделать это с локальной машины (от сервера к себе), но не от serverB к serverA под учетными данными serverAadministrator.

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

$cred = get-credential - Я набрал свой домен\имя пользователя и пароль

затем я использовал IP-адрес вместо параметра hostname in-ComputerName, поэтому enter-pssession выглядит так:

Enter-Pssession -ComputerName 192.168.1.111 -Credential $cred

этот подход работает и для команды invoke-command

invoke-command -ComputerName 192.168.1.111 -Credential $cred -ScriptBlock

Я до сих пор не знаю, почему он не работает с хоста и почему я должен создать $cred, но поскольку мне нужно быстрое решение, это отлично работает для меня.

Спасибо за помощь.

у меня была точно такая же проблема. С помощью FQDN работал для меня.

это явно ошибка разрешения DNS; особенно если IP-адрес работает. Я бы рискнул сказать, что есть проблемы маршрутизации суффикса имени.

на Имя_компьютера описание говорит, что имя NETBIOS должно работать, но это не в моем тестировании в моем окружении. FQDN-еще один вариант для -Имя_компьютера собственность и исправлена эта ошибка для меня.

попробуйте использовать (используйте свой FQDN, конечно):

Примечание: у меня не было проблемы с Ввод-Сеанс PSSession

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

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

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

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

запуск Enable-PSRemoting на локальном компьютере

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

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

настройка автозапуска для службы WinRM

настройка прослушивателей для HTTP

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

настройка исключений файервола для HTTP

выбор портов для HTTP

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

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

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

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

Trusted Hosts

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

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

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

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

добавление компьютеров в TrustedHosts с помощью powerShell

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

добавление компьютеров в TrustedHosts с помощью групповых политик

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

SSL

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

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

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

создание самоподписанного сертификата

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

сведения о сертификате

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

выбор хранилища для сертификата

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

помещение сертификата в доверенные корневые центры сертификации

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

отпечаток сертификата

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

создание прослушивателя для HTTPS

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

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

создание правила на файерволе для HTTPS

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

certutil -addstore root C:\myssl.cer

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

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

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

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

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

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

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

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

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

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

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

создание прослушивателей на портах 80 и 443

создание прослушивателей на портах 80 и 443 с помощью GPO

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

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

изменение дефолтного порта

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моя цель - выполнить файл PowerShell на удаленном сервере через задачи TFS ' PowerShell on Target Machines ' для этих шагов, которые я предпринял до сих пор:

Как сборка, так и удаленный сервер уже включены

Также добавлены IP-адреса доверенных серверов

После выполнения всех вышеперечисленных шагов по-прежнему появляется следующая ошибка в задаче TFS

Какая будет причина или что мне не хватает чего-либо.

1 ответ

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

Совет 1

Эта проблема может возникнуть, если служба удаленного управления Windows и ее функции прослушивателя нарушены.

Чтобы решить эту проблему, выполните следующие действия:

Шаг 1. Установите последнее обновление удаленного управления Windows.

Шаг 2. Выполните следующую команду, чтобы восстановить конфигурацию слушателя:

Шаг 3. Выполните следующую команду, чтобы выполнить настройку службы удаленного управления Windows и ее прослушивателя по умолчанию:

Щелкните этот документ для получения подробной информации.

Совет 2

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

Щелкните этот документ для получения подробной информации и способов решения проблемы.

Совет 3

Чтобы решить эту проблему:

Шаг 1. Используйте параметры ProxyAccessType , ProxyAuthentication и ProxyCredential командлета New-PSSessionOption , чтобы создать объект параметра сеанса с настройками прокси для вашего предприятия. Сохраните объект опции как переменную.

Шаг 2. Используйте переменную, содержащую объект параметра, в качестве значения параметра SessionOption команды New-PSSession , Enter-PSSession или Invoke-Command .

Щелкните этот документ для получения подробной информации.

Совет 4

Попробуйте запустить файл PowerShell локально и посмотрите, есть ли в нем такая же ошибка.

Читайте также: