Настройка Windows-хоста

В этом документе рассматривается настройка, необходимая перед тем, как Ansible сможет взаимодействовать с хостом Microsoft Windows.

• Требования к хосту
  • Обновление PowerShell и .NET Framework
  • Обновление WinRM (исправление памяти)
• Настройка WinRM
  • Слушатель WinRM
    • Настройка слушателя WinRM
    • Удаление слушателя WinRM
  • Параметры службы WinRM
  • Общие проблемы с WinRM
    • Ошибка HTTP 401/Отклонены учетные данные
    • Ошибка HTTP 500
    • Ошибки таймаута
    • Ошибки "Подключение отклонено"
• Настройка SSH на Windows
  • Установка Win32-OpenSSH
  • Настройка оболочки Win32-OpenSSH
  • Авторизация в Win32-OpenSSH
  • Настройка Ansible для SSH на Windows
  • Известные проблемы с SSH на Windows

Требования к хосту

Для взаимодействия Ansible с Windows-хостом и использования модулей Windows, хост должен соответствовать следующим требованиям:

• Ansible обычно может управлять версиями Windows в рамках текущей и расширенной поддержки Microsoft. Ansible может управлять настольными ОС, включая Windows 7, 8.1 и 10, и серверными ОС, включая Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016 и 2019.
• Ansible требует PowerShell 3.0 или более поздней версии и .NET 4.0 или более поздней версии на Windows-хосте.
• Должен быть создан и активирован слушатель WinRM. Более подробная информация об этом приведена ниже.

Обновление PowerShell и .NET Framework

Ansible требует версию PowerShell 3.0 и .NET Framework 4.0 или более позднюю для работы на старых операционных системах, таких как Server 2008 и Windows 7. Базовый образ не отвечает этому требованию. Вы можете использовать скрипт Upgrade-PowerShell.ps1 для обновления.

Это пример того, как запустить этот скрипт из PowerShell:

$url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Upgrade-PowerShell.ps1"
$file = "$env:temp\Upgrade-PowerShell.ps1"
$username = "Administrator"
$password = "Password"

(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force

# Version can be 3.0, 4.0 or 5.1
&$file -Version 5.1 -Username $username -Password $password -Verbose

После завершения вам потребуется удалить автоматический вход и установить политику выполнения обратно по умолчанию: Restricted. Вы можете сделать это с помощью следующих команд PowerShell:

# This isn't needed but is a good security practice to complete
Set-ExecutionPolicy -ExecutionPolicy Restricted -Force

$reg_winlogon_path = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $reg_winlogon_path -Name AutoAdminLogon -Value 0
Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultUserName -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $reg_winlogon_path -Name DefaultPassword -ErrorAction SilentlyContinue

Скрипт работает, проверяя, какие программы необходимо установить (например, .NET Framework 4.5.2) и какая версия PowerShell требуется. Если требуется перезагрузка, и параметры username и password установлены, скрипт автоматически перезагрузит систему и выполнит вход при возвращении из перезагрузки. Скрипт будет продолжать работу, пока не потребуются дополнительные действия, и версия PowerShell не будет соответствовать целевой версии. Если параметры username и password не установлены, скрипт попросит пользователя вручную перезагрузить систему и выполнить вход, когда это потребуется. После следующего входа пользователя скрипт продолжит с того места, где остановился, и процесс продолжается, пока не потребуются дополнительные действия.

Обновление WinRM (исправление памяти)

При работе с PowerShell v3.0 существует ошибка службы WinRM, которая ограничивает объем памяти, доступной для WinRM. Без установки этого исправления Ansible не сможет выполнить определенные команды на Windows-хосте. Эти исправления должны быть установлены как часть процесса загрузки или создания образов системы. Скрипт Install-WMF3Hotfix.ps1 можно использовать для установки исправления на затронутые хосты.

Следующая команда PowerShell установит исправление:

$url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Install-WMF3Hotfix.ps1"
$file = "$env:temp\Install-WMF3Hotfix.ps1"

(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file -Verbose

Дополнительную информацию см. в документе оправке от Microsoft.

Настройка WinRM

После обновления Powershell до версии не менее 3.0, следующим шагом является настройка службы WinRM таким образом, чтобы Ansible мог к ней подключиться. Существует две основные компоненты службы WinRM, регулирующие то, как Ansible может взаимодействовать с Windows-хостом: настройки listener и service.

Подробнее о каждом компоненте можно прочитать ниже, но скрипт ConfigureRemotingForAnsible.ps1 можно использовать для базовой настройки. Этот скрипт настраивает слушатели HTTP и HTTPS с самоподписанным сертификатом и включает параметр аутентификации Basic в службе.

Для использования этого скрипта выполните следующую команду в PowerShell:

$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:temp\ConfigureRemotingForAnsible.ps1"

(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)

powershell.exe -ExecutionPolicy ByPass -File $file

Существуют различные переключатели и параметры (например, -EnableCredSSP и -ForceNewSSLCert) , которые можно задать вместе с этим скриптом. Документация по этим параметрам находится вверху самого скрипта.

Слушатель WinRM

Служба WinRM прослушивает запросы на одном или нескольких портах. Каждый из этих портов должен иметь созданный и настроенный слушатель.

Для просмотра текущих слушателей, работающих на службе WinRM, выполните следующую команду:

winrm enumerate winrm/config/Listener

Вывод будет примерно таким:

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.0.2.15, 127.0.0.1, 192.168.56.155, ::1, fe80::5efe:10.0.2.15%6, fe80::5efe:192.168.56.155%8, fe80::
ffff:ffff:fffe%2, fe80::203d:7d97:c2ed:ec78%3, fe80::e8ea:d765:2c69:7756%7

Listener
    Address = *
    Transport = HTTPS
    Port = 5986
    Hostname = SERVER2016
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint = E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE
    ListeningOn = 10.0.2.15, 127.0.0.1, 192.168.56.155, ::1, fe80::5efe:10.0.2.15%6, fe80::5efe:192.168.56.155%8, fe80::
ffff:ffff:fffe%2, fe80::203d:7d97:c2ed:ec78%3, fe80::e8ea:d765:2c69:7756%7

В приведенном выше примере активированы два слушателя; один прослушивает порт 5985 по протоколу HTTP, а другой — порт 5986 по протоколу HTTPS. Некоторые из ключевых параметров, которые полезно понять:

• Transport: Протокол слушателя (HTTP или HTTPS). Рекомендуется использовать HTTPS, так как данные шифруются без дополнительных изменений.
• Port: Порт, на котором работает слушатель. По умолчанию это 5985 для HTTP и 5986 для HTTPS. Этот порт можно изменить на требуемый и он соответствует переменной хоста ansible_port.
• URLPrefix: Префикс URL для прослушивания, по умолчанию wsman. Если этот параметр изменить, переменная хоста ansible_winrm_path должна быть установлена на то же значение.

• CertificateThumbprint: При использовании HTTPS-слушателя это отпечаток сертификата в хранилище сертификатов Windows, который используется при подключении. Чтобы получить сведения о самом сертификате, выполните следующую команду с соответствующим отпечатком сертификата в PowerShell:

  $thumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE"
  Get-ChildItem -Path cert:\LocalMachine\My -Recurse | Where-Object { $_.Thumbprint -eq $thumbprint } | Select-Object *
  

Настройка слушателя WinRM

Существует три способа настройки слушателя WinRM:

• Используя winrm quickconfig для HTTP или winrm quickconfig -transport:https для HTTPS. Это самый простой способ использования вне среды домена, когда требуется простой слушатель. В отличие от других вариантов, этот процесс также имеет дополнительное преимущество открытия брандмауэра для необходимых портов и запуска службы WinRM.
• Использование объектов групповой политики. Это лучший способ создания слушателя, когда хост является членом домена, так как настройка выполняется автоматически без какого-либо вмешательства пользователя. Для получения дополнительной информации об объектах групповой политики см. документацию по объектам групповой политики.

• Использование PowerShell для создания слушателя со специфической конфигурацией. Это можно сделать, выполнив следующие команды PowerShell:

  $selector_set = @{
      Address = "*"
      Transport = "HTTPS"
  }
  $value_set = @{
      CertificateThumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE"
  }
  
  New-WSManInstance -ResourceURI "winrm/config/Listener" -SelectorSet $selector_set -ValueSet $value_set
  

  Чтобы увидеть другие параметры с этим командлетом PowerShell, см. New-WSManInstance.

Удаление слушателя WinRM

Для удаления слушателя WinRM:

# Remove all listeners
Remove-Item -Path WSMan:\localhost\Listener\* -Recurse -Force

# Only remove listeners that are run over HTTPS
Get-ChildItem -Path WSMan:\localhost\Listener | Where-Object { $_.Keys -contains "Transport=HTTPS" } | Remove-Item -Recurse -Force

Параметры службы WinRM

Существует ряд параметров, которые можно настроить для управления поведением компонента службы WinRM, включая параметры аутентификации и настройки памяти.

Чтобы получить вывод текущих параметров конфигурации службы, выполните следующую команду:

winrm get winrm/config/Service
winrm get winrm/config/Winrs

Это выведет что-то вроде:

Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = false
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = true
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true

Winrs
    AllowRemoteShellAccess = true
    IdleTimeout = 7200000
    MaxConcurrentUsers = 2147483647
    MaxShellRunTime = 2147483647
    MaxProcessesPerShell = 2147483647
    MaxMemoryPerShellMB = 2147483647
    MaxShellsPerUser = 2147483647

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

• Service\AllowUnencrypted: Этот параметр определяет, будет ли WinRM разрешать трафик, передаваемый по протоколу HTTP без шифрования сообщений. Шифрование на уровне сообщений возможно только тогда, когда ansible_winrm_transport имеет значение ntlm, kerberos или credssp. По умолчанию это false, и следует устанавливать значение true только при отладке сообщений WinRM.
• Service\Auth\*: Эти флаги определяют, какие параметры аутентификации разрешены службой WinRM. По умолчанию включены Negotiate (NTLM) и Kerberos.
• Service\Auth\CbtHardeningLevel: Определяет, проверяются ли токены привязки канала (None), проверяются, но не требуются (Relaxed), или проверяются и требуются (Strict). CBT используется только при подключении с использованием NTLM или Kerberos по протоколу HTTPS.
• Service\CertificateThumbprint: Это отпечаток сертификата, используемого для шифрования канала TLS, используемого с аутентификацией CredSSP. По умолчанию он пуст; самозаверяющий сертификат генерируется при запуске службы WinRM и используется в процессе TLS.
• Winrs\MaxShellRunTime: Это максимальное время в миллисекундах, в течение которого разрешено выполнение удалённой команды.
• Winrs\MaxMemoryPerShellMB: Это максимальный объем памяти, выделенный на сеанс, включая дочерние процессы сеанса.

Чтобы изменить настройку в ключе Service в PowerShell:

# substitute {path} with the path to the option after winrm/config/Service
Set-Item -Path WSMan:\localhost\Service\{path} -Value "value here"

# for example, to change Service\Auth\CbtHardeningLevel run
Set-Item -Path WSMan:\localhost\Service\Auth\CbtHardeningLevel -Value Strict

Чтобы изменить настройку в ключе Winrs в PowerShell:

# Substitute {path} with the path to the option after winrm/config/Winrs
Set-Item -Path WSMan:\localhost\Shell\{path} -Value "value here"

# For example, to change Winrs\MaxShellRunTime run
Set-Item -Path WSMan:\localhost\Shell\MaxShellRunTime -Value 2147483647

Общие проблемы с WinRM

Поскольку WinRM имеет широкий спектр параметров конфигурации, настройка и конфигурация могут быть сложными. Из-за этой сложности проблемы, которые демонстрирует Ansible, могут на самом деле быть проблемами с настройкой хоста.

Один из простых способов определить, является ли проблема проблемой хоста, — это запустить следующую команду с другого узла Windows для подключения к целевому узлу Windows:

# Test out HTTP
winrs -r:http://server:5985/wsman -u:Username -p:Password ipconfig

# Test out HTTPS (will fail if the cert is not verifiable)
winrs -r:https://server:5986/wsman -u:Username -p:Password -ssl ipconfig

# Test out HTTPS, ignoring certificate verification
$username = "Username"
$password = ConvertTo-SecureString -String "Password" -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password

$session_option = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Invoke-Command -ComputerName server -UseSSL -ScriptBlock { ipconfig } -Credential $cred -SessionOption $session_option

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

HTTP 401/Отклонены учетные данные

Ошибка HTTP 401 указывает на то, что процесс аутентификации завершился неудачно во время первоначального подключения. Следует проверить следующие моменты:

• Убедитесь, что учетные данные верны и правильно заданы в вашем инвентаре с помощью ansible_user и ansible_password
• Убедитесь, что пользователь является членом локальной группы Администраторы или ему был явно предоставлен доступ (можно использовать команду тестирования соединения winrs, чтобы исключить эту возможность).
• Убедитесь, что параметр аутентификации, заданный ansible_winrm_transport, включен в Service\Auth\*
• Если выполняется подключение по HTTP, а не HTTPS, используйте ntlm, kerberos или credssp с ansible_winrm_message_encryption: auto, чтобы включить шифрование сообщений. Если используется другой параметр аутентификации или если установленная версия pywinrm не может быть обновлена, Service\AllowUnencrypted можно установить на true, но это рекомендуется только для устранения неполадок.
• Убедитесь, что зависимые пакеты pywinrm, requests-ntlm, requests-kerberos, и/или requests-credssp обновлены с помощью pip.
• При использовании аутентификации Kerberos убедитесь, что Service\Auth\CbtHardeningLevel не установлено на Strict.
• При использовании аутентификации по паролю или сертификату убедитесь, что пользователь — это локальный аккаунт, а не доменный. Доменные аккаунты не работают с аутентификацией по паролю и сертификату.

Ошибка HTTP 500

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

• Убедитесь, что количество открытых сеансов не превысило WinRsMaxShellsPerUser или другие квоты Winrs не превышены.

Ошибки таймаута

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

• Убедитесь, что брандмауэр не блокирует заданные порты слушателя WinRM.
• Убедитесь, что на заданном порту и пути хоста включён слушатель WinRM.
• Убедитесь, что служба winrm запущена на узле Windows и настроена на автоматический запуск.

Ошибки отказа в подключении

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

• Убедитесь, что служба WinRM запущена и работает на хосте. Используйте (Get-Service -Name winrm).Status для получения статуса службы.
• Проверьте, что брандмауэр хоста разрешает трафик через порт WinRM. По умолчанию это 5985 для HTTP и 5986 для HTTPS.

Иногда установщик может перезапустить службу WinRM или HTTP, вызывая эту ошибку. Лучший способ решения этой проблемы — использовать win_psexec с другого хоста Windows.

Настройка Windows SSH

В Ansible 2.8 добавлена экспериментальная возможность SSH-подключения для управляемых узлов Windows.

Установка Win32-OpenSSH

Первым шагом для использования SSH с Windows является установка службы Win32-OpenSSH на хосте Windows. Microsoft предлагает способ установить Win32-OpenSSH через возможности Windows, но в настоящее время версия, установленная таким образом, слишком устарела для работы с Ansible. Чтобы установить Win32-OpenSSH для использования с Ansible, выберите один из трёх вариантов установки:

• Установите службу вручную, следуя инструкциям по установке от Microsoft.

• Используйте win_chocolatey для установки службы:

  - name: install the Win32-OpenSSH service
    win_chocolatey:
      name: openssh
      package_params: /SSHServerFeature
      state: present
  

• Используйте существующий Ansible Galaxy-рол, такой как jborean93.win_openssh:

  # Make sure the role has been downloaded first
  ansible-galaxy install jborean93.win_openssh
  
  # main.yml
  - name: install Win32-OpenSSH service
    hosts: windows
    gather_facts: no
    roles:
    - role: jborean93.win_openssh
      opt_openssh_setup_service: True
  

Настройка оболочки Win32-OpenSSH

По умолчанию Win32-OpenSSH будет использовать cmd.exe в качестве оболочки. Чтобы настроить другую оболочку, используйте задачу Ansible для определения настройки реестра:

- name: set the default shell to PowerShell
  win_regedit:
    path: HKLM:\SOFTWARE\OpenSSH
    name: DefaultShell
    data: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    type: string
    state: present

# Or revert the settings back to the default, cmd
- name: set the default shell to cmd
  win_regedit:
    path: HKLM:\SOFTWARE\OpenSSH
    name: DefaultShell
    state: absent

Аутентификация Win32-OpenSSH

Аутентификация Win32-OpenSSH с Windows аналогична аутентификации SSH на Unix/Linux-хостах. Вы можете использовать аутентификацию по паролю в текстовом формате или по открытому ключу SSH, добавить открытые ключи в файл authorized_key в папке .ssh каталога профиля пользователя и настроить службу с использованием файла sshd_config, используемого службой SSH, как вы это делали на Unix/Linux-хосте.

При использовании аутентификации по открытому ключу SSH с Ansible удалённая сессия не будет иметь доступа к учетным данным пользователя и завершится неудачей при попытке доступа к сетевому ресурсу. Это также известно как проблема двойного хопа или делегирования учетных данных. Существуют два способа решения этой проблемы:

• Используйте аутентификацию по паролю в текстовом формате, установив ansible_password
• Используйте become в задаче с учетными данными пользователя, которому необходим доступ к удалённому ресурсу.

Настройка Ansible для SSH на Windows

Чтобы настроить Ansible для использования SSH для хостов Windows, необходимо установить две переменные соединения:

• установите ansible_connection на ssh
• установите ansible_shell_type на cmd или powershell

Переменная ansible_shell_type должна отражать DefaultShell , настроенный на хосте Windows. Установите значение cmd для стандартной оболочки или powershell , если DefaultShell изменено на PowerShell.

Известные проблемы с SSH на Windows

Использование SSH с Windows экспериментально, и мы ожидаем обнаружения дополнительных проблем. Вот известные из них:

• Версии Win32-OpenSSH, более ранние, чем v7.9.0.0p1-Beta не работают, когда powershell является типом оболочки.
• Хотя SCP должен работать, SFTP — рекомендуемый механизм передачи файлов SSH для копирования или извлечения файла.