Добавление компьютера в winrm. Выполнение консольных команд на удаленных компьютерах по сети. Что такое WinRS и как его использовать

В этой статье, я попытаюсь рассказать, каким образом можно централизованно активировать и настроить службу Windows Remote Management (WinRM) на всех целевых компьютерах с помощью групповой политики. Напомню, что Windows Remote Management – это специальный сервис, позволяющий администраторам получить возможность удаленного доступа и управления клиентскими и серверными ОС Windows (и, думаю, если вы ранее пользовались набором утилит Microsoft Sysinternals , то WRM должен вам понравиться).
Возьмем обычный ПК с , и на котором не активирована функция Windows Remote Management. В командной строке введем следующую команду:

, должно появиться следующее сообщение об ошибке, свидетельствующее о том, что WRM не установлен:
WSMan Fault. The client cannot connect to the destination specified in the request. Error number: — 2144108526 0x80338012

Если нужно настроить WinRM вручную на отдельной системе, достаточно набрать команду:

Winrm quickconfig

В том случае, если нужно настроить WinRM на группе компьютеров, то можно воспользоваться специальными параметрами групповой политики. Интересующая нас политика находится в разделе: Computer Configuration -> Policies -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service. Нужно активировать следующие параметры:
Allow automatic configuration of listeners
Allow Basic Authentication

В разделе IPv4 filter укажем *, что означает, что компьютер может принимать подключения (а значит и управляющие команды) откуда угодно, это значит что листенеры на компьютере будет принимать запросы на всех IP интерфейсах.


Затем в разделе Computer Configuration -> Policies -> Windows Components -> Windows Remote Shell активируем пункт:
Allow Remote Shell Access


И, наконец, нужно задать тип запуска у службы Windows Remote Service в «Автоматический» (Automatically). Напомню, что управлять способом запуска служб можно из следующего раздела групповых политик: Computer Configuration -> Windows Settings -> Security Settings ->System Services.


После активации WinRM с помощью групповой политики, на клиентской системе проверим статус службы с помощью знакомой команды:

Удостоверимся, что тип запуска службы WinRM задан в автоматический. Хотя по факту тип запуска «автоматический с задержкой», т.к. по умолчанию для службы WinRM задана задержка запуска (параметр DelayedAutoStart=1 в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinRM).

Теперь, после активации WinRM с помощью групповой политики, данной системой можно управлять удаленно с помощью команд WinRS. Следующая команда откроет командную строку, запущенную на удаленной системе:

Winrs –r:computer01 cmd

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

17.10.2011 Дон Джоунз

Я понял, что создатели PowerShell были несколько ленивы, и это хорошо. Они не хотели кодировать параметр -ComputerName для каждой команды, поэтому создали общую систему под названием «удаленное взаимодействие». По существу, эта система активирует любую команду для запуска на удаленном компьютере. Вы даже можете запускать разные команды, которые существуют на удаленном компьютере, но отсутствуют на вашем. Это означает, что вам не нужно постоянно устанавливать каждую команду на своей рабочей станции. Эта удаленная система очень эффективна и дает ряд интересных административных возможностей

Когда я начал использовать PowerShell, я увлекся командой Get-Service и заметил, что у нее есть параметр -ComputerName. Не означает ли это, что можно подключиться к службе и с других компьютеров? После проведения ряда экспериментов я обнаружил, что это как раз то, что написано. Я заинтересовался и принялся искать параметры -ComputerName у других команд. И расстроился, когда выяснил, что их было только несколько.

PowerShell обеспечивает два типа удаленного взаимодействия: удаленное взаимодействие один к одному (1:1) и удаленное взаимодействие один к нескольким (1:n). Прежде чем рассказать о них, хочу пояснить некоторые основы.

Основы удаленного взаимодействия в PowerShell

Удаленное взаимодействие PowerShell работает почти как Telnet и другие старые технологии удаленного управления. Когда вы запускаете команду, она на самом деле запускается на удаленном компьютере. Все, что возвращается на ваш компьютер, является результатом работы этой команды. В отличие от Telnet или Secure Shell (SSH), PowerShell использует новый протокол системы связи, который называется Web Services for Management (WS-Management). Протокол действует поверх HTTP или HTTP Secure (HTTPS), что облегчает прокладывание маршрута через брандмауэры, если это необходимо, поскольку протокол использует только один порт для установления связи. Реализация WS-Management от Microsoft идет в форме фоновой службы, которая называется Windows Remote Management. WinRM устанавливается вместе с PowerShell 2.0 и запускается по умолчанию на серверах, подобных Windows Server 2008 R2. На Windows 7 она устанавливается по умолчанию, но не активируется. Необходимо активировать WinRM на тех компьютерах, на которые вы хотите послать команду. Компьютер, за которым вы находитесь физически, не нуждается в запуске службы WinRM.

Все команды PowerShell производят объекты в качестве выходных данных. Когда вы запускаете команду удаленно, ее выходные данные нужно облечь в форму, которую можно легко передавать по сети, используя протокол HTTP или HTTPS. Так, PowerShell автоматически преобразует выходные объекты в файлы XML, которые передаются по сети. Достигнув вашего компьютера, они преобразовываются обратно в объекты, с которыми может работать PowerShell. Однако эти преобразованные обратно объекты на самом деле являются мгновенными снимками. Они не могут обновлять сами себя ежеминутно. Таким образом, если вы должны добраться до объектов, которые представляют собой процессы, запускаемые на удаленном компьютере, то полученный результат будет верен только для конкретного промежутка времени, в течение которого эти объекты были сгенерированы. Значения, такие как использование памяти и процессора, не изменятся. Более того, вы не сможете заставить преобразованные обратно объекты сделать что-либо. Например, вы не можете приказать объекту остановить самого себя. Это основное ограничение удаленного взаимодействия, но оно не помешает вам работать и выполнять интересные задачи.

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

• Как ваш компьютер (он же локальный компьютер) и один из тех, которым вы хотите послать команду (он же удаленный компьютер), должны работать с Windows PowerShell 2.0? Windows XP является устаревшей версией Windows, на которую вы можете установить PowerShell 2.0. Таким образом, старая версия тоже может принимать участие в удаленной сессии.
• В идеале локальный и удаленный компьютеры должны быть членами одного домена или членами доверенных/доверяющих доменов. С системой удаленного взаимодействия можно работать и вне домена, но это сложно, и здесь я об этом рассказывать не буду. Чтобы узнать больше об этом сценарии, обратитесь к разделу PowerShell Help, где говорится о Remote_Troubleshooting.

Обзор WinRM

Теперь перейдем к WinRM, поскольку вам необходимо задавать настройки этой службы для запуска удаленного взаимодействия. Опять повторюсь, требуется только задать настройки удаленного взаимодействия WinRM и PowerShell на удаленном компьютере. В большинстве сред, в которых я работал, администраторы активировали систему удаленного взаимодействия на каждом компьютере, работающем с версиями XP или более новыми. Это дает возможность проникать в настольные и портативные компьютеры незаметно, что может быть очень полезным (это означает, что пользователи таких компьютеров не будут знать, что вы делаете).

Нельзя сказать, что WinRM представляет собой что-то особенное для PowerShell. WinRM может прокладывать трафик к нескольким административным приложениям. По существу, WinRM действует как диспетчер. Когда трафик появляется, WinRM решает, какое приложение должно взаимодействовать с ним, и помечает его именем приложения-адресата. Принимающее приложение должно зарегистрироваться в WinRM, таким образом WinRM сможет прослушивать входящий трафик от его имени. Другими словами, вам нужно не только активировать WinRM, но и зарегистрировать Power Shell как конечную точку для WinRM.

Самым простым способом выполнения обеих задач является запуск PowerShell от имени администратора и выполнение команды Enable-PSRemoting. Вы можете посмотреть руководство по другой команде, которая называется Set-WSManQuickConfig. Нет нужды запускать команду. Это сделает за вас Enable-PSRemoting, и она же выполняет еще несколько шагов, которые необходимы для установления удаленного взаимодействия и работы. В сущности, команда Enable-PSRemoting запускает службу WinRM, задает ее настройки для запуска автоматически, регистрирует PowerShell как конечную точку и даже устанавливает исключения в Windows Firewall для того, чтобы разрешить входящий трафик WinRM.

Если вам не хочется обходить все компьютеры ради активации удаленного взаимодействия, можно задействовать объект групповой политики Group Policy Object (GPO). Необходимые настройки GPO встроены в контроллеры домена Windows Server 2008 R2. Просто откройте GPO и идите по маршруту Computer Configuration\

Administrative Templates\Windows Components. Внизу списка вы найдете как Remote Shell, так и Windows Remote Management (WRM), настройки которых нужно задать. Раздел Help о проблемах системы удаленного взаимодействия (Remote_Troubleshooting) даст вам детальные инструкции о том, как это сделать. Просмотрите разделы How to Enable Remoting in an Enterprise и How to Enable Listeners by Using a Group Policy в Help.

WinRM 2.0 (который применяется PowerShell) по умолчанию использует порт TCP 5985 для HTTP и порт 5986 для HTTPS. Это гарантирует, что WinRM не будет конфликтовать с локально установленными веб-серверами, которые настроены на прослушивание портов 80 и 443. Вы можете задать настройки WinRM для использования альтернативных портов, но я не рекомендую этого делать. Ели вы оставите эти порты, все команды удаленного доступа PowerShell будут работать нормально. Если вы измените эти порты, вам придется всегда указывать альтернативный порт при запуске команды удаленного доступа. Это означает, что вам придется больше печатать. Если вам крайне необходимо изменить порт, можете ввести команду:

Winrm set winrm/config/ listener? Address=* +Transport=HTTP @{Port="1234"}

Цифры 1234 означают порт, который вам нужен. Здесь эта команда написана в несколько строк, но вам нужно вводить ее в одну строку. То же самое касается и всех других команд, описанных в статье. Если необходимо использовать HTTPS вместо http, вы можете видоизменить эту команду, чтобы настроить новый порт HTTPS. Должен признаться, что есть способ задать настройки WinRM на локальных компьютерах для того, чтобы задействовать альтернативные порты по умолчанию. Таким образом, вам не нужно постоянно определять альтернативный порт, когда вы запускаете команду удаленного доступа. Но давайте поработаем с настройками по умолчанию, заданными Microsoft.

Если покопаться в настройках GPO в Remote Shell, вы заметите, что можете задать, например, насколько долго удаленная сессия будет оставаться неактивной до того, как сервер прервет ее; как много одновременно действующих пользователей могут обращаться к удаленному серверу за один раз; как много памяти и процессов каждая удаленная оболочка может использовать; максимальное количество удаленных оболочек, которые пользователи могут открывать за один раз. Эти настройки помогут убедиться, что ваши серверы не перегружены забывчивыми администраторами. Однако по умолчанию необходимо быть администратором, чтобы использовать удаленное взаимодействие, поэтому вам не стоит беспокоиться об обычных пользователях, засоряющих ваши серверы.

Удаленное взаимодействие 1:1

Используя удаленное взаимодействие 1:1, вы, по существу, получаете доступ к командной строке на одном удаленном компьютере. Любые команды, которые вы даете, запускаются прямо на удаленном компьютере, а вы видите результаты в окне командной строки. Отчасти это похоже на использование Remote Desktop Connection, если не считать того, что вы ограничены средой командной строки PowerShell. Система удаленного взаимодействия PowerShell использует часть ресурсов, которые требует Remote Desktop, поэтому она оказывает намного меньшее воздействие на ваши серверы.

Для того чтобы установить соединение 1:1 с удаленным компьютером, названным Server-R2, нужно запустить

Enter-PSSession -Computername Server-R2

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

PS C:\>

Часть информирует вас о том, что все, что вы делаете, происходит на Server-R2. После этого вы можете запустить любые команды, какие хотите. Вы даже можете импортировать любые модули и добавить расширения PowerShell (PSSnapins), которые будут располагаться на удаленном компьютере.

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

• Если у вас есть сценарий PowerShell для вашего профиля на удаленном компьютере, он не будет запускаться, когда вы подсоединитесь, используя систему удаленного доступа. Проще говоря, профили являются пакетом команд, которые автоматически запускаются каждый раз, когда вы открываете окно командной строки. Они используются для автоматической загрузки расширений, модулей и тому подобного.
• Вы ограничены политикой Execution Policy удаленного компьютера. Скажем, политика вашего компьютера устанавливается на RemoteSigned так, что вы можете запускать локальные неподписанные сценарии. Если политика удаленного компьютера установлена в Restricted (настройка по умолчанию), она не позволит запускать никакие сценарии, когда вы взаимодействуете удаленно.

Многие команды PowerShell идут в парах: одна делает нечто, другая - противоположное этому. В нашем случае Enter-PSSession подсоединяет вас к удаленному компьютеру, а Exit-PSSession закрывает это соединение. Exit-PSSession не нужны никакие параметры. После запуска удаленное соединение закрывается, и приглашение вашего окна командной строки возвращается обратно к нормальному виду. А что если вы забудете запустить Exit-PSSession? Не беспокойтесь. PowerShell и WinRM способны выяснить, что вы сделали, и закрыть в случае необходимости удаленное соединение.

Хочу дать один совет. Когда вы подсоединяетесь к удаленному компьютеру, не запускайте на нем Enter-PSSession до тех пор, пока полностью не осознаете, что вы делаете. Например, вы работаете на ComputerА. Вы подсоединяетесь к Server-R2. В строке PowerShell вы запускаете

PS C:\> Enter-PSSession Server-DC4

Теперь Server-R2 содержит открытое соединение с Server-DC4. Это создает «цепь удаленного взаимодействия», которую отследить сложно. Кроме того, ваши серверы без надобности оказываются перегруженными. Могут быть моменты, когда вы должны будете делать это (например, Server-DC4 находится за брандмауэром и вы не можете получить к нему прямой доступ, поэтому в качестве посредника вам нужно использовать Server-R2). Однако общее правило состоит в следующем: старайтесь избегать цепочек удаленного взаимодействия.

Удаленное взаимодействие 1:n

Одна из самых интересных вещей в PowerShell - это удаленное взаимодействие 1: n. Оно позволяет вам отсылать команды на несколько удаленных компьютеров одновременно - полномасштабные распределенные вычисления. Каждый компьютер по отдельности будет выполнять команду и отсылать вам результаты. Все делается при помощи команды Invoke-Command в таком виде:

Invoke-Command -ComputerName Server-R2, Server-DC4, Server12 -Command {Get-EventLog Security -Newest 200 | Where {$_.EventID -eq 1212}}

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

Единственный параметр, которого вы не увидите на странице Help этой команды, - параметр Command. Он, как я уже показал, работает прекрасно. Параметр Command является псевдонимом или кратким именем для параметра ScriptBlock, который указан на странице Help. Для меня проще использовать Command, поэтому я склонен задействовать именно его вместо ScriptBlock, однако они работают одинаково.

Если вы прочитали страницу Help для Invoke-Command внимательно, вы также заметили параметр, который позволяет указывать файл сценария, а не команду. Параметр FilePath позволяет посылать сценарий на удаленные компьютеры; это означает, что вы можете автоматизировать некоторые сложные задачи, а каждый компьютер будет выполнять свою долю работы.

Теперь остановимся на параметре Computer Name. В примере кода Invoke-Command у меня был список имен компьютера, разделенный запятыми. Если у вас много компьютеров, то вы, возможно, не хотите печатать их имена каждый раз, когда подсоединяетесь к ним. Вместо этого вы можете создать текстовый файл, который содержит по одному имени компьютера на одной строке, без запятых, кавычек или чего-то еще. Например, если бы ваш текстовый файл был назван webservers.txt, вы бы использовали такой код:

Invoke-Command -Command { dir } -ComputerName (Get-Content webservers.txt)

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

Возможен также запрос имени компьютера в Active Directory, но это сложнее. Для того чтобы найти компьютер, вы можете использовать команду Get-ADComputer, но вы не вставите эту команду в круглые скобки, как делали это в Get-Content. Почему нет? Get-Content выдает простые текстовые строки, тогда как Get-ADComputer производит объекты типа «компьютер». Параметр -ComputerName ожидает строки. Если бы он должен был получать объекты «компьютер», то не знал бы, что с ними делать. Поэтому, если вы хотите использовать Get-ADComputer, вам нужно получить значения из свойства Name компьютерных объектов. Вот так:

Invoke-Command -Command {dir} -ComputerName (Get-ADComputer -Filter * -SearchBase "ou=Sales, dc=company, dc=pri" | Select-Object -Expand Name)

В круглых скобках компьютерные объекты передаются команде Select-Object, а параметр -Expand используется для выяснения свойства Name этих компьютерных объектов. Результат выражения в скобках - это набор имен компьютера, а не компьютерных объектов. Имена компьютеров - это как раз то, что нужно параметру -Computer Name.

Если вы не знакомы с Get-ADComputer, давайте посмотрим, что делает эта команда. Параметр -Filter определяет, что все компьютеры должны быть включены в результаты, а параметр -Search Base предписывает PowerShell, чтобы он начал искать компьютеры в организационной группе Sales (OU) в домене company.pri. Команда Get-ADComputer доступна только в Windows Server 2008 R2 и в Windows 7 после установки набора утилит Remote Server Administration Tools. В этих операционных системах вы запускаете

Import-Module ActiveDirectory

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

Есть кое-что еще!

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

Чтобы создать постоянные сессии, нужно использовать команду New-PSSession, затем сохранить их в переменной для легкого доступа. Например, следующий код создает сессию удаленного взаимодействия с тремя компьютерами и сохраняет их в переменной $sessions:

$sessions = New-PSSession -ComputerName One, Two, Three -Port 5555 -Credential DOMAIN\Administrator

Сессии удаленного взаимодействия закрываются автоматически, когда вы закрываете командную оболочку, но до этого времени они могут занимать память и немного загружать процессор на локальной и удаленной системах. Для того чтобы точно закрыть их, вы можете использовать команду Remove-PSSession:

$sessions | Remove-PSSession

Когда вам нужно вновь открыть сессии, вы можете задействовать команду Invoke-Command:

Invoke-Command -Command {dir} -Session $sessions

Или можете применить Enter-PSSession:

Enter-PSSession -Session $session

Заметьте, что в коде Enter-PSSession только одна сессия удаленного взаимодействия открывается повторно. Переменная индекса 1 сообщает PowerShell, что он должен вновь открыть сессию с компьютером, названным Two (индекс отсчитывается с нулевого значения).

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

Дон Джоунз ([email protected]) - технический инструктор по PowerShell (www.windowsitpro.com/go/DonJonesPowerShell), автор более 35 книг. Имеет звание Microsoft MVP

У меня как-то раз возникли проблемы с WinRM на двух серверах.

1. SETSPN
На одном проблема была в том, что SPN записи HTTP/<имя сервера> были зарегистрирована для какой-то "левой" учётной записи пользователя.

Нашёл эти записи командой
setspn -F -Q */<имя сервера>

Затем удалил их командами
setspn -D http/<имя сервера>.<имя домена> <имя домена>\<левая учётная запись>
setspn -D http/<имя сервера> <имя домена>\<левая учётная запись>

Затем enable-psremoting -force выполнилась успешно.

2. LANGUAGE PACK
А на втором сервере была хитрая проблема якобы с фаерволлом Unable to check the status of the firewall , перерыл кучу сайтов, а решение обнаружил интуитивно основываясь на ответе по поводу установленного Language Pack.

WinRm QuickConfig
WinRM service is already running on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.

Error number: -2147024894 0x80070002
The system cannot find the file specified.

В ответе было написно, что данная ошибка лечится удалением дополнительного Language Pack.
Но я поступил иначе. У меня Английская операционка с дополнительным русским language pack. Я просто изменил язык интерфейса на Русский.
Панель управления, Язык и региональные стандарты, Языки и клавиатуры изменил язык интерфейса с англиского на русский.
Выполнил logoff и вошёл снова. Открыл PowerShell и повторил WinRm QuickConfig

PS C:\Windows\system32> winrm qc

Служба WinRM не настроена на разрешение удаленного управления компьютером.
Необходимо внести следующие изменения:

Создайте прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.

Выполнить изменения ? y

Служба WinRM обновлена для удаленного управления.

Создан прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.

Выполнилось успешно, но всё же не достаточно.

Появилась ошибка Access Denied при попытке выполнить команды удалённо на этом сервере с другого компа.

New-PSSession: [<имя сервера>] Connecting to remote server <имя сервера> failed with the following error message: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.

Тогда я повторил Enable-PsRemoting

PS C:\Windows\system32> Enable-PsRemoting

Быстрая настройка WinRM
Запуск команды "Set-WSManQuickConfig" для включения на данном компьютере удаленного управления с помощью службы WinRM.
Необходимые действия.
1. Запуск или перезапуск (если уже запущена) службы WinRM.
2. Изменение типа службы WinRM на "автозапуск".
3. Создание прослушивателя для приема запросов на любом IP-адресе.
4. Настройка исключений брандмауэра для трафика службы WS-Management (только для протокола http).

Продолжить?

(значением по умолчанию является "Y"):a
Служба WinRM уже настроена на прием запросов на компьютере.
Служба WinRM уже настроена на разрешение удаленного управления компьютером.

Подтверждение
Вы действительно хотите выполнить это действие?
Выполнение операции "Регистрация конфигурации сеанса" над целевым объектом "Конфигурация сеанса
"Microsoft.PowerShell32" не найдена. Будет выполнена команда "Register-PSSessionConfiguration Microsoft.PowerShell32
-processorarchitecture x86 -force" для создания конфигурации сеанса "Microsoft.PowerShell32". Служба WinRM будет
перезапущена.".
[Y] Да - Y [A] Да для всех - A [N] Нет - N [L] Нет для всех - L [S] Приостановить - S [?] Справка
(значением по умолчанию является "Y"):a

После этого WinRM на этом сервере заработал как надо.

Бывают случаи, когда требуется выполнить какую-либо команду на сервере локально (например, сконфигурировать iSCSI Initiator). Подключаться для этого через Remote Desktop и запускать cmd - неудобно, использовать Telnet - небезопасно, ставить на сервер демона ssh - не... хочется...

Специально для таких запущенных случаев, Microsoft, начиная с Windows Server 2003 R2, снабдила администраторов новым средством управления - Windows Remote Management (WinRM), позволяющим удаленно выполнять команды, используя стандартные средства ОС, и обеспечивая при этом должный уровень безопасности.

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


Настройка WinRM
В качестве примера я рассмотрю процесс настройки WinRM на Windows Server 2008. Эта процедура никак не отличается от настройки WinRM, например, на Windows Vista или Hyper-V Server.

Проще всего WinRM настроить можно, используя режим быстрой конфигурации, набрав в CMD:
winrm quickconfig
и ответив утвердительно ("y ") на вопрос о создании нового объекта-listener"а, прослушающего порт TCP 80, и использующего протокол HTTP для коммуникаций между клиентом и сервером.

И все, сервером можно управлять удаленно, используя команду:
winrs -r:<ИМЯ_СЕРВЕРА> <КОМАНДА>
,где <ИМЯ_СЕРВЕРА> - имя или IP адрес сервера, к которому осуществляется подключение;
<КОМАНДА> - удаленная команда, которую требуется выполнить.

Если клиент и сервер не являются членами одного домена, вам потребуется дополнительно указать имя пользователя из-под которого будет запускаться команда и его пароль:
winrs -r:<ИМЯ_СЕРВЕРА> -u:<ИМЯ_ПОЛЬЗОВАТЕЛЯ> -p:<ПАРОЛЬ> <КОМАНДА>

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

Для добавления узла в список надежных, выполните на клиенте, с которого планируете подключаться:
winrm set winrm/config/client @{TrustedHosts="<ИМЯ_УЗЛА1> [,<ИМЯ_УЗЛА2> ]"}

После настройки вы можете получить информацию о существующих listener"ах с помощью команды:
winrm enumerate winrm/config/listener

Удалить существующий listener можно следующим образом:
winrm delete winrm/config/listener?Address=*+Transport=HTTPS

Настройка WinRM с использованием HTTPS
В ряде случаев вам может потребоваться создать надежный канал для безопасной пересылки команд между клиентом и сервером. Для этого можно использовать HTTPS.

Однако, для создания listener"а с поддержкой HTTPS вам потребуется цифровой сертификат, который можно запросить у доверенного Центра Сертификации, либо воспользоваться различными утилитами по созданию самоподписанных (самозаверенных) сертификатов, например, Makecert, входящей в состав Windows SDK . Скачать Makecert отдельно можно отсюда .

Для создания самоподписанного серитификата выполните следующую команду:
makecert -a sha1 -r -pe -n "CN=<ИМЯ_СЕРВЕРА> " -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 <ФАЙЛ_СЕРТИФИКАТА>
, где <ИМЯ_СЕРВЕРА> соответствует имени, которое будет использовать клиент при подключении к серверу;
<ФАЙЛ_СЕРТИФИКАТА> - путь к файлу, куда будет сохранен сертификат с открытым ключем.

Сертификат с закрытым ключем будет создан и помещен в хранилище сертификатов локального компьютера. Добавьте его к доверенным корневым сертификатам:
certutil -addstore root cert.cer

Теперь просмотрите хранилище сертификатов, найдите там требуемый сертификат и запишите его Thumbprint (Cert Hash):
certutil -store my

Наконец, можно приступать к созданию HTTPS listener. Введите команду:
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<ИМЯ_УЗЛА> ";CertificateThumbprint="<ХЭШ_СЕРТИФИКАТА> ";Port="<ПОРТ> "}
,где <ИМЯ_УЗЛА> - имя, которое указывается при обращении к серверу
<ХЭШ_СЕРТИФИКАТА> - Thumbprint, который вы узнали на предыдущем шаге (без пробелов).
<ПОРТ> - порт, на который будет подключаться клиент (TCP 443 по-умолчанию).

Если на сервере включен брандмауэр Windows, не забудьте добавить правило:
netsh advfirewall firewall add rule name="allow WinRM on 4443" protocol=TCP dir=in localport=4443 action=allow

При использовании самоподписанных сертификатов, вам придется добавить его к доверенным корневым сертификатам на клиенте.

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

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

Собственно WinRM (или Windows Remote Management ) и переводится как «удаленное управление Windows» . WinRM – служба удаленного управления для операционных систем Windows . Она входит в состав операционных систем начиная с Vista и Server 2008 , для Windows XP и Server 2003 ее нужно устанавливать отдельно отсюда . WinRM – серверная часть приложения удаленного управления, к которому возможно удаленное подключение с помощью клиента Windows Remote Shell (WinRS).

WinRM основан на службах Web Services for Management (WS-Management) и использует протокол HTTP (порт 80) или HTTPS (443) и запросы SOAP для выполнения работы. Независимо от используемого протокола весь трафик, передаваемый WinRM шифруется (если специально не отключить эту опцию). Для аутентификации по умолчанию используется протокол Kerberos .

В Windows Server 2008 WinRM установлен, но (по соображениям безопасности) по умолчанию не включен. Чтобы проверить, запущен ли WinRM на нашей машине, набираем в командной строке winrm enumerate winrm/config/listener

Если ответа нет, значит WinRM не запущен. Для того, чтобы настроить WinRM на автоматический запуск и разрешить удаленное подключение к компьютеру, набираем команду winrm quickconfig или winrm qc

Чтобы WinRM не спрашивал подтверждения, можно добавить к вызову ключ -quiet . Узнать информацию о более тонкой настройке можно посмотреть встроенную справку WinRM : winrm help config

Ну и отключить WinRM можно с помощью такой команды:
winrm delete winrm/config/listener?IPAdress=*+Transport=HTTP

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

• Настроить службу WinRM на автоматический запуск
• Разрешить подключения на соответствующие порты (80 и 443) в брандмауэре Windows
• Настроить элемент групповой политики Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Удаленное управление Windows\Служба удаленного управления Windows\Разрешить автоматическую установку прослушивателей (Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management \WinRM Service\Allow automatic configuration of listeners) . Тут нужно будет указать IP-адреса, с которых разрешаются подключения.

Теперь перейдем непосредственно к использованию. Для подключения к удаленному компьютеру используем утилиту WinRS . WinRS – аббревиатура для Windows Remote Shell (удаленная среда Windows ). С WinRS мы можем делать удаленные запросы на компьютеры, на которых запущен WinRM . Однако имейте ввиду, что на вашей машине также необходимо запускать WinRM для работы с WinRS .

Основным способом использования WinRS является выполнение команд на удаленной машине. Имя компьютера задаётся ключом -r , а после него следует выполняемая команда, например winrs – r : SRV 2 ipconfig / all запускает на удаленном компьютере SRV2 команду ipconfig / all

По умолчанию для коммуникаций используется протокол http , но можно использовать и https : winrs -r:https://SRV2 ipconfig /all

Также можно с помощью WinRS открыть интерактивный сеанс на удалённом компьютере: winrs -r:SRV2 cmd.exe

Эта функция аналогична подключению по telnet , но использование WinRS однозначно лучше с точки зрения безопасности.

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

« true»}

« »}

WinRM set winrm/config/client @{TrustedHosts=« ComputerName»}

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

На компьютере, с которого будем подключаться, вводим:

WinRM set winrm/config/service/auth @{Basic=« true»}

WinRM set winrm/config/client @{TrustedHosts=« »}

WinRM set winrm/config/client @{TrustedHosts= «ComрuterName»}

где ComputerName — компьютер, которым будем управлять.

Затем устанавливаем соедининие с помощью команды:

winrs -r: «ComputerName»: –u: Domain\Username –p: Password cmd.exe

где Domain\Username — учетная запись пользователя с административными правами на удаленном компьютере.