PowerShell Remoting (PSRemoting) – одна из самых популярных функций в PowerShell. Почему? Потому что она на самом деле очень полезна! С помощью одной команды вы можете без проблем подключиться к одному или тысячам удаленных компьютеров и выполнять команды.
В этом исчерпывающем руководстве вы узнаете все о PSRemoting. Вы узнаете, что это такое, как оно работает и какие технологии используются для его работы. В данном руководстве не будет рассказано, как использовать PSRemoting. Вы найдете множество ссылок на наши руководства по использованию во время чтения данного руководства.
Как работает PSRemoting
В двух словах, PSRemoting позволяет выполнять команды на удаленных компьютерах так, как будто вы сидите перед ними. PSRemoting предоставляет набор функций, которые устанавливают соединение, аутентифицируют пользователя, выполняют удаленные команды и возвращают вывод этих команд на локальный компьютер.
Можно сравнить PSRemoting с telnet, SSH или даже psexec. Это просто способ выполнять команды на компьютерах в рамках PowerShell.
PSRemoting тесно связан с понятием сеанса. Сеанс – это термин, используемый для описания удаленной оболочки, в которой выполняются команды. Процесс создания одного из этих сеансов включает в себя множество шагов в фоновом режиме.
Когда вы инициируете сеанс PSRemoting, выполняются следующие приблизительные шаги:
- Клиент пытается подключиться к серверу назначения через слушатель WinRM (подробнее о слушателях WinRM ниже). Слушатель WinRM – это небольшая веб-служба, которая работает на сервере назначения. WinRM – это реализация Microsoft стандарта WSMan. WSMan – это открытый стандарт, созданный совместными усилиями таких крупных технологических компаний, как Dell, Intel и Sun Microsystems
- Когда клиент подключается к слушателю по протоколам HTTP или HTTPS, начинается процесс аутентификации. Подробности каждого метода аутентификации будут рассмотрены позже, но на данный момент просто знайте, что клиент должен передать учетные данные серверу каким-либо образом.
- После подключения клиента и его аутентификации на сервере, PSRemoting создает сеанс.
- После создания сеанса PSRemoting готов к работе. На этом этапе клиент может начать отправлять информацию на сервер, а сервер возвращает любой необходимый вывод, известный как сериализация. Это общение обычно зашифровано.
Слушатели WinRM: доступны для подключения
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
Вы можете найти все слушатели WinRm, работающие на любом компьютере с Windows, используя команду winrm ниже.
У слушателей WinRm есть несколько важных компонентов. Они имеют:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- Тип транспорта – каждый слушатель WinRM должен иметь способ общения с клиентом; они делают это с помощью транспорта, используя либо HTTP, либо HTTPS.
- Необязательный отпечаток сертификата – когда слушатель WinRM использует HTTPS для транспорта, ему необходимо знать, какой закрытый ключ использовать для аутентификации клиента; этот ключ находится с помощью отпечатка сертификата.
Используйте слушатель HTTPS, когда это возможно. Настройка транспорта HTTPS повышает безопасность, обеспечивая подлинность сервера и шифрование как аутентификации, так и транспортного трафика. При выдаче сертификата используйте доверенный сертификат от удостоверяющего центра, если возможно, а не самоподписанный сертификат.
Доверенные хосты: проверка сервера
Как работает аутентификация PSRemoting в WinRM
Как указано выше, одним из первых этапов, через которые проходит PSRemoting, является аутентификация. Аутентификация является одной из самых сложных, но в то же время наиболее важных частей PSRemoting.
Когда PSRemoting был впервые представлен, у него был только один механизм аутентификации, Windows Remote Management (WinRM), но в настоящее время вы также можете аутентифицироваться с помощью SSH, о чем вы увидите позже.
WinRM поддерживает два различных типа аутентификации: имя пользователя и пароль или сертификат с различными типами аутентификации для комбинации имя пользователя/пароль.
Базовая аутентификация
Начнем с самого простого, но наименее безопасного типа аутентификации – Базовая аутентификация. Этот тип аутентификации является стандартом, встроенным в протокол HTTP. Базовая аутентификация отправляет в заголовке HTTP от клиента к слушателю копию имени пользователя и пароля в кодировке base64.
Поскольку базовая аутентификация только кодирует имя пользователя и пароль, а не шифрует их, перехватить учетные данные по сети довольно просто.
Не используйте базовую аутентификацию, если у вас нет необходимости. Существует множество более безопасных методов аутентификации в WinRM!
Аутентификация Kerberos
Ваш клиент и сервер находятся в среде Active Directory? Если да, то вы уже используете аутентификацию Kerberos для многих сетевых служб.
Когда клиент WinRM пытается подключиться к слушателю WinRM по протоколу Kerberos:
- Сервер сначала пытается получить ключ сеанса или билет для клиента от контроллера домена.
- Контроллер домена проверяет клиента и сервер, и если оба действительны и доверенны, выдает токен.
- Затем сервер проверяет подключение клиента с использованием доверенного токена, а не имени пользователя и пароля.
Во время аутентификации Kerberos контроллер домена проверяет как клиента, так и сервер на этапе получения билета, что предотвращает возможность злоумышленника выдавать себя за сервер.
Kerberos – это зрелый и безопасный метод аутентификации, который является типом аутентификации по умолчанию, когда клиент и сервер являются участниками домена Active Directory. Однако это требует, чтобы и клиент, и сервер были присоединены к одной и той же лесу Active Directory или была настроена доверительная связь между лесами.
Аутентификация по протоколу “Negotiate”
WinRm также может попытаться использовать Kerberos, а если это невозможно, то перейти к использованию протокола аутентификации, называемого NT Lan Manager (NTLM).
При использовании NTLM:
- Сервер отправляет клиенту строку.
- Затем клиент шифрует строку с помощью хэша пароля пользователя.
- Зашифрованная строка затем отправляется обратно на сервер, который отправляет имя пользователя, исходную строку и зашифрованную строку контроллеру домена.
- Контроллер домена затем ищет хэш пароля для этого пользователя и повторяет тот же процесс шифрования для проверки соответствия.
NTLM хорошо подходит для проверки клиента, но, в отличие от Kerberos, он не проверяет сервер. Это открывает возможность для нескольких атак, где сервер может быть подменен злоумышленником.
Вы можете улучшить безопасность NTLM, также проверив сервер с помощью сертификата аутентификации сервера и привязав его к слушателю HTTPS WinRM. В этой настройке клиент аутентифицируется с помощью NTLM на контроллере домена, а сервер аутентифицируется с помощью доверенного сертификата. Хотя эта настройка обеспечивает аутентификацию клиента и сервера, протокол NLTM использует устаревший шифр с устаревшим размером ключа.
Поэтому NLTM может быть использован только в случае добавления сервера в список доверенных хостов или использования слушателя HTTPS.
Аутентификация Digest
Одним из наиболее необычных методов аутентификации, используемых в WinRM, является аутентификация Digest. NTLM и Digest – похожие методы аутентификации. Как и NTLM, Digest генерирует уникальную строку, которая шифруется с помощью хэша пароля пользователя. Пароль не передается на сервер.
Для шифрования пароля в Digest используется алгоритм хэширования MD5. Из-за выбора этого алгоритма Digest обычно считается устаревшим и не рекомендуется к использованию. MD5 имеет известные уязвимости, которые делают его непригодным для криптографического использования.
Провайдер поддержки безопасности учетных данных (CredSSP)
Хотя мы могли бы зайти в подробности CredSSP, это не обязательно. Почему? Потому что, когда речь идет о PSRemoting и WinRM, CredSSP обычно реализуется по одной причине – “проблеме второго перехода”, о которой вы узнаете ниже.
При настройке аутентификации CredSSP клиент и сервер WinRM используют аутентификацию через переговоры для проверки подлинности пользователя и клиента. Однако, после завершения процесса аутентификации, пароль пользователя отправляется на сервер.
Поскольку пароль отправляется после завершения процесса аутентификации, он теперь зашифрован. CredSSP также шифрует пароль с использованием ключей сеанса TLS , чтобы зашифрованная строка была уникальной между сеансами.
CredSSP полезен, потому что после аутентификации сервер может подключиться к чему угодно от вашего имени. Однако, когда это происходит, вы полностью доверяете серверу, с которым вы подключились, с паролем пользователя.
Аутентификация на основе сертификатов
Можно сказать, что самым безопасным способом аутентификации при использовании PSRemoting является аутентификация на основе сертификатов. При этом способе аутентификации происходит обмен типичными ключами с закрытым и открытым ключами на клиенте и сервере, проверяющих сертификат.
WinRM аутентифицирует пользователя, отображая пользователя на сервере внутри WinRM. В процессе аутентификации передается только открытый ключ, поэтому это очень безопасный способ аутентификации.
Хотя это самый безопасный способ, аутентификация на основе сертификатов не слишком распространена. Почему? Просто из-за необходимой предварительной работы для ее настройки. Вам нужно:
- Создать сертификатный центр
- Создать сертификат аутентификации пользователя
- Поделиться открытым ключом
- Использовать локальную учетную запись пользователя с соответствующими разрешениями (вероятно, группа Администраторов)
- Настроить слушателя HTTPS
- … и другие шаги.
Вы не можете использовать учетную запись домена для аутентификации с помощью сертификатов, даже если клиент и сервер являются частью Active Directory.
Параметры аутентификации по умолчанию в операционной системе Windows
Теперь, когда вы видели, что доступно множество различных вариантов аутентификации, как узнать, какие из них доступны изначально? Ниже приведена таблица с двумя столбцами, указывающими, включен ли клиент WinRM по умолчанию, и включен ли данный тип аутентификации по умолчанию.
Все вышеперечисленные типы аутентификации настраиваемы, но использование таблицы ниже даст вам представление о том, что вам нужно настроить самостоятельно.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
Проблема “второго перехода” или “двойного перехода”
Одной из самых больших проблем с использованием PSRemoting является “проблема второго перехода” или “двойного перехода”. Эта ситуация возникает, когда вы подключаетесь к удаленной системе через PSRemoting, а затем вам необходимо подключиться к другому удаленному компьютеру.
Эта ситуация проблематична, потому что при аутентификации клиента WinRm на первом удаленном компьютере сервер только проверяет подлинность идентификатора исходного клиента, не отправляя пароль на сервер. Когда вы пытаетесь подключиться ко второму компьютеру с сервера первого подключения, конечному серверу не предоставляется возможность проверить подлинность пользователя.
Вы можете решить проблему двойного перехода несколькими способами, используя либо CredSSP, либо делегирование Kerberos.
Использование CredSSP
Наиболее распространенным способом обхода проблемы двойного перехода является использование CredSSP. Аутентификация CredSSP обходит эту ситуацию, сохраняя учетные данные пользователя на первом удаленном сервере, которые сервер-клиент может передать второму удаленному серверу.
Однако есть одно ограничение при использовании CredSSP. Учетные данные пользователя, хранящиеся на первом удаленном сервере, могут быть сохранены в открытом виде, что представляет очевидную угрозу безопасности. В более новых операционных системах используется хэш пароля и билет Kerberos для выдачи билетов, которые могут использоваться вместе для аутентификации пользователя в любой точке сети, подобно паролю в открытом виде, но это снижает риск немного.
С помощью протокола Negotiate клиент и сервер обмениваются информацией для проверки подлинности, но пароль пользователя никогда не доступен. Из-за этой функции безопасности первый сервер не может аутентифицировать вас при подключении ко второму серверу.
Использование делегирования Kerberos
Как уже упоминалось ранее, Kerberos – это общепринятый способ настройки PSRemoting. Будучи частью всеобщего Active Directory и настроенным по умолчанию, он очень распространен. Хотя Kerberos сам по себе является хорошим способом аутентификации для WinRM, он не решает проблему двойного перехода.
Чтобы обойти проблему двойного перехода, вы можете использовать второй тип аутентификации, известный как делегирование Kerberos. Хотя существует много разновидностей делегирования Kerberos, единственный вариант, способный заменить CredSSP и обеспечивающий достаточную безопасность, называется ограниченное делегирование Kerberos (Kerberos Constrained Delegation), а именно ограниченное делегирование Kerberos, основанное на ресурсах.
Ограниченное делегирование Kerberos на основе ресурсов представляет собой форму делегирования токенов аутентификации Kerberos на основе ресурсов домена, таких как компьютеры, в данном случае, ограниченных определенным списком объектов Kerberos (Active Directory).
Для настройки делегирования Kerberos необходимо изменить объект ADComputer третьего компьютера в цепочке. Например, если вы собираетесь удаленно подключиться с клиента A к серверу B, а затем к серверу C, вам нужно изменить объект ADComputer для сервера C, но также необходимо знать, каким будет сервер B. Для этого примера выполните следующую команду в PowerShell:
Использование делегирования Kerberos на основе ресурсов работает для удаленных подключений, например, … или …, но не будет работать с использованием PSRemoting. Вы не сможете подключиться к третьему компьютеру, когда подключены к компьютеру по протоколу WinRM с использованием PSRemoting.
Настройка ограниченного делегирования Kerberos на основе ресурсов – это однолинейная команда PowerShell с использованием командлета Set-ADComputer. Например, если вы подключены к серверу B с клиента A по протоколу PSRemoting и хотите подключиться к серверу C с помощью …, вы можете выполнить следующую команду PowerShell.
WinRm кэширует неудачные подключения в течение 15 минут. Из-за этой функции вы можете не смочь подключиться к третьему компьютеру даже после настройки ограниченного делегирования Kerberos на основе ресурсов. Чтобы исправить ситуацию, подождите или выполните команду
klist purge -LI 0x3e7на третьем компьютере, чтобы очистить неудачные токены Kerberos.
Как работает аутентификация PSRemoting через SSH
Хотя аутентификация WinRm является наиболее распространенным методом аутентификации для PSRemoting, начиная с PowerShell v6, у вас есть еще один способ – SSH. Использование SSH в качестве метода аутентификации позволяет использовать PSRemoting с Linux.
В отличие от WinRm, SSH требует дополнительной конфигурации как на клиенте, так и на сервере, например, настройки SSH-клиента на клиенте Windows и …
Использование SSH для аутентификации означает, что вы ограничены типами аутентификации, поддерживаемыми SSH. Это сужает список, главными из которых являются аутентификация на основе пароля и на основе открытого ключа.
Есть и другие типы аутентификации, поддерживаемые SSH, но они обычно считаются менее безопасными, чем варианты на основе пароля и открытого ключа, поэтому мы сосредоточимся только на этих двух.
Аутентификация по паролю
Самый простой способ настроить аутентификацию SSH с помощью PSRemoting – это аутентификация на основе пароля. Аутентификация на основе пароля позволяет вам предоставить пароль для проверки вашей подлинности.
В процессе аутентификации SSH пароль обменивается после установления SSH-соединения, и пароль шифруется во время передачи. В отличие от некоторых методов аутентификации, используемых WinRM, таких как Kerberos, этот метод аутентификации отправляет полный пароль на сервер.
Можно относительно сравнить аутентификацию по паролю SSH с методом аутентификации WinRM Basic, используя слушатель HTTPS. Сам пароль не защищен особым образом, но всё соединение, включая пароль, шифруется, и сервер проверяется по сертификату.
Сертификатная аутентификация (Certificate-Based Authentication)
Хотя аутентификация на основе пароля легка в настройке и проста в использовании, она имеет две проблемы.
- Первая заключается в том, что нет способа безопасно аутентифицироваться в автономном режиме.
- При аутентификации по паролю пароль все равно отправляется по сети. Хотя пароль шифруется внутри SSH-соединения, сервер получает полный пароль. Если сервер каким-либо образом скомпрометирован, это может стать проблемой безопасности.
С другой стороны, сертификатная аутентификация не отправляет по сети никакие конфиденциальные данные, такие как пароль. Вместо этого сервер имеет копию открытого ключа, клиент имеет копию закрытого ключа, и взаимодействие происходит на сервере.
A rough workflow goes as follows:
- Когда клиент пытается аутентифицироваться, он отправляет идентификатор или отпечаток публичного ключа на сервер.
- Если сервер имеет отпечаток публичного ключа в списке разрешенных, он отвечает строкой, зашифрованной с помощью публичного ключа.
- Затем клиент расшифровывает строку с помощью закрытого ключа.
- Затем закрытый ключ хешируется с идентификатором сеанса.
- Идентификатор сеанса отправляется обратно на сервер, который затем сравнивает его с хешем, сгенерированным с использованием исходной строки и идентификатора сеанса.
- Если хеш идентификатора сеанса с клиента и идентификатор сеанса на сервере совпадают, клиент проходит аутентификацию и ему разрешено подключение.
Все, что зашифровано с помощью открытого ключа, может быть расшифровано только с помощью соответствующего закрытого ключа. Все, что зашифровано с помощью закрытого ключа, может быть расшифровано только с помощью открытого ключа. Идентификатор сеанса также добавляется для обеспечения так называемой Перфектной прямой секретности (PFS).
PFS обеспечивает безопасность в случае компрометации закрытого ключа, злоумышленник не сможет расшифровать все сообщения, которые были переданы туда и обратно. Уникальный идентификатор сеанса означает, что общий секрет, используемый для шифрования связи, отличается для каждого сеанса.
Аутентификация на основе сертификата с использованием SSH, также как и WinRm, требует дополнительных усилий для настройки, таких как генерация закрытого/открытого ключа и авторизация открытого ключа на удаленном сервере.
Права пользователя, необходимые для подключения
По умолчанию, две локальные группы пользователей могут подключаться к серверу удаленно с использованием PSRemoting: Администраторы и Пользователи удаленного управления.
В то время как вы можете просто добавить учетные записи пользователей в группу локальных администраторов на удаленном сервере, всегда следует предоставлять наименьший уровень доступа. Если пользователю просто нужно подключиться с помощью PSRemoting к удаленному компьютеру, его учетная запись может быть добавлена в группу Пользователи удаленного управления, а не в группу Администраторы.
Для дополнительного контроля доступа к PSRemoting можно также использовать функцию, называемую Только необходимая администрация (JEA). JEA позволяет неадминистраторам выполнять только определенные команды от имени администраторов в режиме ограниченного языка PowerShell.
Неявное и «явное» удаленное управление
Если вы уже использовали PSRemoting ранее, вам, вероятно, знакомы команды, такие как Invoke-Command, New-PSSession, Enter-PSSession и т. д. Когда вы выполняете эти команды, очевидно, что вы somehow подключаетесь к удаленному компьютеру. Вы явно используете PSRemoting.
Когда вы выполняете команды, специфичные для PSRemoting, вы явно выполняете эти команды, но знаете ли вы, что есть и другой способ? Вместо непосредственного вызова команды Invoke-Command и других cmdlet’ов вы можете использовать PSRemoting с помощью неявного PSRemoting.
Неявное PSRemoting может выглядеть так, как будто вы выполняете команды локально в рамках вашей сессии PowerShell, но на самом деле они выполняются на удаленном компьютере. Хорошим примером этого является использование модуля, который не установлен на вашей системе. Вместо его установки локально вы можете экспортировать команды из PSSession, что позволит вам выполнять их так, как если бы они были установлены локально.
На скриншоте ниже вы можете видеть, что у меня нет команды Test-PendingReboot. Затем я подключился к удаленному компьютеру и экспортировал эту команду.
Затем, если этот модуль импортирован, я могу выполнить команду Test-PendingReboot. Это показано ниже, но вы заметите, что в выводе отображается имя компьютера, не являющееся именем устройства, откуда запущен PowerShell, а именно устройства, из которого была импортирована команда.
