Настройка хоста 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, хост Windows должен соответствовать следующим требованиям:

• Поддерживаемые Ansible версии Windows, как правило, совпадают с версиями, которые находятся под текущей и расширенной поддержкой Microsoft. Поддерживаемые настольные операционные системы включают 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. Нижние библиотеки, которые в настоящее время использует Ansible, поддерживают передачу CBT только с аутентификацией NTLM. Использование Kerberos с CbtHardeningLevel = Strict приведет к ошибке 404.
• 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.
• При использовании аутентификации Basic или сертификата убедитесь, что пользователь является локальным, а не доменным пользователем. Доменные учетные записи не работают с аутентификацией Basic и сертификатом.

Ошибка 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.

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

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 для копирования или извлечения файла