Ejemplo de configuración de un host de Windows de Ansible

Este documento describe la configuración necesaria antes de que Ansible pueda comunicarse con un host de Microsoft Windows.

• Requisitos de host

  • Actualización de PowerShell y .NET Framework
  • Revisión de memoria WinRM

• Configuración de WinRM

  • Oyente de WinRM

    • Configurar el oyente de WinRM
    • Eliminar el oyente de WinRM
  • Opciones de servicio WinRM

  • Problemas comunes de WinRM

    • HTTP 401 / Credenciales rechazadas
    • Error HTTP 500
    • Errores de tiempo de espera
    • Errores de conexión rechazada
    • Error al cargar módulos integrados

• Configuración de SSH de Windows

  • Instalación de Win32-OpenSSH
  • Configuración del shell Win32-OpenSSH
  • Autenticación Win32-OpenSSH
  • Configuración de Ansible para SSH en Windows
  • Problemas conocidos con SSH en Windows

Requisitos de host

Para que Ansible se comunique con un host de Windows y utilice módulos de Windows, el host de Windows debe cumplir estos requisitos:

• Ansible generalmente puede administrar las versiones de Windows con el soporte actual y extendido de Microsoft. Ansible puede administrar sistemas operativos de escritorio, incluidos Windows 7, 8.1 y 10, y sistemas operativos de servidor, incluidos Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016 y 2019.
• Ansible requiere PowerShell 3.0 o más reciente y al menos .NET 4.0 para estar instalado en el host de Windows.
• Debe crearse y activarse un oyente de WinRM. Más detalles para esto se pueden encontrar a continuación.

Nota

Si bien estos son los requisitos básicos para la conectividad de Ansible, algunos módulos de Ansible tienen requisitos adicionales, como un sistema operativo más nuevo o una versión de PowerShell. Consulte la página de documentación del módulo para determinar si un host cumple con esos requisitos.

Actualización de PowerShell y .NET Framework

Ansible requiere PowerShell versión 3.0 y .NET Framework 4.0 o más reciente para funcionar en sistemas operativos más antiguos como Server 2008 y Windows 7. La imagen base no cumple con este requisito. Puedes usar el Upgrade-PowerShell.ps1 script para actualizarlos.

Este es un ejemplo de cómo ejecutar este script desde PowerShell:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Upgrade-PowerShell.ps1"
$file = "$env:tempUpgrade-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

Una vez completado, deberá eliminar el inicio de sesión automático y volver a establecer la política de ejecución a la predeterminada (Restricted `` for Windows clients, or ``RemoteSigned para servidores Windows). Puede hacer esto con los siguientes comandos de PowerShell:

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

$reg_winlogon_path = "HKLM:SoftwareMicrosoftWindows NTCurrentVersionWinlogon"
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

El script funciona comprobando qué programas deben instalarse (como .NET Framework 4.5.2) y qué versión de PowerShell se requiere. Si es necesario reiniciar y el username y password configurados, la secuencia de comandos se reiniciará e iniciará sesión automáticamente cuando vuelva del reinicio. El script continuará hasta que no se requieran más acciones y la versión de PowerShell coincida con la versión de destino. Si el username y password los parámetros no están configurados, el script le pedirá al usuario que reinicie e inicie sesión manualmente cuando sea necesario. La próxima vez que el usuario inicie sesión, el script continuará donde lo dejó y el proceso continuará hasta que no se requieran más acciones.

Nota

Si se ejecuta en Server 2008, se debe instalar SP2. Si se ejecuta en Server 2008 R2 o Windows 7, se debe instalar SP1.

Nota

Windows Server 2008 solo puede instalar PowerShell 3.0; si especifica una versión más reciente, el script fallará.

Nota

los username y password los parámetros se almacenan en texto sin formato en el registro. Asegúrese de que los comandos de limpieza se ejecuten después de que finalice el script para asegurarse de que no se almacenen credenciales en el host.

Revisión de memoria WinRM

Cuando se ejecuta en PowerShell v3.0, hay un error con el servicio WinRM que limita la cantidad de memoria disponible para WinRM. Sin esta revisión instalada, Ansible no podrá ejecutar ciertos comandos en el host de Windows. Estas revisiones deben instalarse como parte del proceso de creación de imágenes o de arranque del sistema. La secuencia de comandos Install-WMF3Hotfix.ps1 se puede utilizar para instalar la revisión en los hosts afectados.

El siguiente comando de PowerShell instalará la revisión:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/jborean93/ansible-windows/master/scripts/Install-WMF3Hotfix.ps1"
$file = "$env:tempInstall-WMF3Hotfix.ps1"

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

Para obtener más detalles, consulte la Documento de revisión de Microsoft.

Configuración de WinRM

Una vez que Powershell se haya actualizado a al menos la versión 3.0, el paso final es configurar el servicio WinRM para que Ansible pueda conectarse a él. Hay dos componentes principales del servicio WinRM que rigen cómo Ansible puede interactuar con el host de Windows: listener y el service ajustes de configuración.

Los detalles sobre cada componente se pueden leer a continuación, pero el script ConfigureRemotingForAnsible.ps1 se puede utilizar para configurar los conceptos básicos. Este script configura los escuchas HTTP y HTTPS con un certificado autofirmado y habilita la Basic opción de autenticación en el servicio.

Para usar este script, ejecute lo siguiente en PowerShell:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:tempConfigureRemotingForAnsible.ps1"

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

powershell.exe -ExecutionPolicy ByPass -File $file

Hay diferentes interruptores y parámetros (como -EnableCredSSP y -ForceNewSSLCert) que se puede configurar junto con este script. La documentación de estas opciones se encuentra en la parte superior del propio script.

Nota

El script ConfigureRemotingForAnsible.ps1 está diseñado para fines de capacitación y desarrollo únicamente y no debe usarse en un entorno de producción, ya que habilita configuraciones (como Basic autenticación) que puede ser intrínsecamente inseguro.

Oyente de WinRM

Los servicios WinRM escuchan solicitudes en uno o más puertos. Cada uno de estos puertos debe tener un escucha creado y configurado.

Para ver los oyentes actuales que se ejecutan en el servicio WinRM, ejecute el siguiente comando:

winrm enumerate winrm/config/Listener

Esto generará algo como:

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

En el ejemplo anterior, hay dos oyentes activados; uno está escuchando en el puerto 5985 a través de HTTP y el otro está escuchando en el puerto 5986 a través de HTTPS. Algunas de las opciones clave que es útil comprender son:

• Transport: Ya sea que el oyente se ejecute a través de HTTP o HTTPS, se recomienda utilizar un oyente a través de HTTPS, ya que los datos están cifrados sin que se requieran más cambios.
• Port: El puerto en el que se ejecuta el oyente, por defecto es 5985 para HTTP y 5986 para HTTPS. Este puerto se puede cambiar a lo que sea necesario y corresponde a la var de host ansible_port.
• URLPrefix: El prefijo de URL para escuchar, por defecto es wsman. Si esto se cambia, el host var ansible_winrm_path debe establecerse en el mismo valor.

• CertificateThumbprint: Si se ejecuta sobre un oyente HTTPS, esta es la huella digital del certificado en la Tienda de certificados de Windows que se usa en la conexión. Para obtener los detalles del certificado en sí, ejecute este comando con la huella digital del certificado correspondiente en PowerShell:

  $thumbprint = "E6CDAA82EEAF2ECE8546E05DB7F3E01AA47D76CE"
  Get-ChildItem -Path cert:LocalMachineMy -Recurse | Where-Object  $_.Thumbprint -eq $thumbprint | Select-Object *
  

Configurar el oyente de WinRM

Hay tres formas de configurar un oyente de WinRM:

• Utilizando winrm quickconfig para HTTP o winrm quickconfig -transport:https para HTTPS. Esta es la opción más fácil de usar cuando se ejecuta fuera de un entorno de dominio y se requiere un escucha simple. A diferencia de las otras opciones, este proceso también tiene el beneficio adicional de abrir el Firewall para los puertos requeridos e inicia el servicio WinRM.
• Uso de objetos de directiva de grupo. Esta es la mejor manera de crear un oyente cuando el host es miembro de un dominio porque la configuración se realiza automáticamente sin ninguna entrada del usuario. Para obtener más información sobre los objetos de política de grupo, consulte la Documentación de objetos de directiva de grupo.

• Usar PowerShell para crear el oyente con una configuración específica. Esto se puede hacer ejecutando los siguientes comandos de PowerShell:

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

  Para ver las otras opciones con este cmdlet de PowerShell, consulte New-WSManInstance.

Nota

Al crear un oyente HTTPS, es necesario crear y almacenar un certificado existente en el LocalMachineMy almacén de certificados. Sin un certificado presente en esta tienda, la mayoría de los comandos fallarán.

Eliminar el oyente de WinRM

Para eliminar un oyente de WinRM:

# Remove all listeners
Remove-Item -Path WSMan:localhostListener* -Recurse -Force

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

Nota

los Keys El objeto es una matriz de cadenas, por lo que puede contener diferentes valores. Por defecto contiene una clave para Transport= y Address= que corresponden a los valores de winrm enumeran winrm / config / Listeners.

Opciones de servicio WinRM

Hay una serie de opciones que se pueden configurar para controlar el comportamiento del componente de servicio WinRM, incluidas las opciones de autenticación y la configuración de la memoria.

Para obtener un resultado de las opciones de configuración del servicio actual, ejecute el siguiente comando:

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

Esto generará algo como:

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

Si bien muchas de estas opciones rara vez deben cambiarse, algunas pueden afectar fácilmente las operaciones en WinRM y son útiles de comprender. Algunas de las opciones importantes son:

• ServiceAllowUnencrypted: Esta opción define si WinRM permitirá el tráfico que se ejecuta a través de HTTP sin cifrado de mensajes. El cifrado a nivel de mensaje solo es posible cuando ansible_winrm_transport es ntlm, kerberos o credssp. Por defecto esto es false y solo debe establecerse en true al depurar mensajes WinRM.
• ServiceAuth*: Estos indicadores definen qué opciones de autenticación están permitidas con el servicio WinRM. Por defecto, Negotiate (NTLM) y Kerberos están habilitados.
• ServiceAuthCbtHardeningLevel: Especifica si los tokens de enlace de canal no se verifican (ninguno), si se verifican pero no son obligatorios (relajado) o si se verifican y son obligatorios (estricto). CBT solo se usa cuando se conecta con NTLM o Kerberos a través de HTTPS.
• ServiceCertificateThumbprint: Esta es la huella digital del certificado utilizado para cifrar el canal TLS utilizado con la autenticación CredSSP. De forma predeterminada, está vacío; se genera un certificado autofirmado cuando se inicia el servicio WinRM y se utiliza en el proceso TLS.
• WinrsMaxShellRunTime: Este es el tiempo máximo, en milisegundos, que se permite ejecutar un comando remoto.
• WinrsMaxMemoryPerShellMB: Esta es la cantidad máxima de memoria asignada por shell, incluidos los procesos secundarios del shell.

Para modificar un ajuste en el Service clave en PowerShell:

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

# for example, to change ServiceAuthCbtHardeningLevel run
Set-Item -Path WSMan:localhostServiceAuthCbtHardeningLevel -Value Strict

Para modificar un ajuste en el Winrs clave en PowerShell:

# Substitute path with the path to the option after winrm/config/Winrs
Set-Item -Path WSMan:localhostShellpath-Value "value here"

# For example, to change WinrsMaxShellRunTime run
Set-Item -Path WSMan:localhostShellMaxShellRunTime -Value 2147483647

Nota

Si se ejecuta en un entorno de dominio, algunas de estas opciones las establece GPO y no se pueden cambiar en el propio host. Cuando una clave se ha configurado con GPO, contiene el texto [Source="GPO"] junto al valor.

Problemas comunes de WinRM

Debido a que WinRM tiene una amplia gama de opciones de configuración, puede ser difícil de instalar y configurar. Debido a esta complejidad, los problemas que muestra Ansible podrían de hecho ser problemas con la configuración del host.

Uno fácil La forma de determinar si un problema es un problema de host es ejecutar el siguiente comando desde otro host de Windows para conectarse al host de Windows de destino:

# 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

Si esto falla, el problema probablemente esté relacionado con la configuración de WinRM. Si funciona, es posible que el problema no esté relacionado con la configuración de WinRM; continúe leyendo para obtener más sugerencias de solución de problemas.

HTTP 401 / Credenciales rechazadas

Un error HTTP 401 indica que el proceso de autenticación falló durante la conexión inicial. Algunas cosas para verificar esto son:

• Verifique que las credenciales sean correctas y estén configuradas correctamente en su inventario con ansible_user y ansible_password
• Asegúrese de que el usuario sea miembro del grupo de administradores locales o que se le haya otorgado acceso explícitamente (una prueba de conexión con el winrs se puede utilizar el comando para descartar esto).
• Asegúrese de que la opción de autenticación establecida por ansible_winrm_transport está habilitado bajo ServiceAuth*
• Si se ejecuta a través de HTTP y no HTTPS, utilice ntlm, kerberos o credssp con ansible_winrm_message_encryption: auto para habilitar el cifrado de mensajes. Si usa otra opción de autenticación o si la versión de pywinrm instalada no se puede actualizar, el ServiceAllowUnencrypted se puede configurar en true pero esto solo se recomienda para solucionar problemas
• Asegurar los paquetes posteriores pywinrm, requests-ntlm, requests-kerberosy / o requests-credssp están al día usando pip.
• Si usa la autenticación Kerberos, asegúrese de que ServiceAuthCbtHardeningLevel no está configurado para Strict.
• Cuando utilice la autenticación básica o de certificado, asegúrese de que el usuario sea una cuenta local y no una cuenta de dominio. Las cuentas de dominio no funcionan con la autenticación básica y de certificado.

Error HTTP 500

Estos indican que se ha producido un error con el servicio WinRM. Algunas cosas para verificar incluyen:

• Verifique que el número de proyectiles abiertos actuales tampoco haya superado WinRsMaxShellsPerUser o cualquiera de las otras cuotas de Winrs no se ha excedido.

Errores de tiempo de espera

Por lo general, indican un error con la conexión de red en el que Ansible no puede comunicarse con el host. Algunas cosas para verificar incluyen:

• Asegúrese de que el firewall no esté configurado para bloquear los puertos de escucha WinRM configurados
• Asegúrese de que un oyente de WinRM esté habilitado en el puerto y la ruta establecidos por las vars del host
• Asegúrese de que el winrm el servicio se está ejecutando en el host de Windows y está configurado para inicio automático

Errores de conexión rechazada

Por lo general, indican un error al intentar comunicarse con el servicio WinRM en el host. Algunas cosas para verificar:

• Asegúrese de que el servicio WinRM esté funcionando en el host. Usar (Get-Service -Name winrm).Status para obtener el estado del servicio.
• Verifique que el firewall del host permita el tráfico a través del puerto WinRM. Por defecto esto es 5985 para HTTP y 5986 para HTTPS.

A veces, un instalador puede reiniciar el servicio WinRM o HTTP y provocar este error. La mejor manera de lidiar con esto es usar win_psexec desde otro host de Windows.

Error al cargar módulos integrados

Si powershell falla con un mensaje de error similar a The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded. entonces podría haber un problema al intentar acceder a todas las rutas especificadas por el PSModulePath Variable ambiental. Una causa común de este problema es que el PSModulePath La variable de entorno contiene una ruta UNC a un recurso compartido de archivos y, debido al problema de delegación de doble salto / credencial, el proceso de Ansible no puede acceder a estas carpetas. La forma de solucionar este problema es:

• Elimine la ruta UNC de la PSModulePath variable de entorno, o
• Utilice una opción de autenticación que admita la delegación de credenciales como credssp o kerberos con la delegación de credenciales habilitada

Ver KB4076842 para obtener más información sobre este problema.

Configuración de SSH de Windows

Ansible 2.8 ha agregado una conexión SSH experimental para los nodos administrados de Windows.

Advertencia

Utilice esta función bajo su propio riesgo. El uso de SSH con Windows es experimental, la implementación puede realizar cambios incompatibles con versiones anteriores en las versiones de funciones. Los componentes del lado del servidor pueden no ser confiables dependiendo de la versión que esté instalada.

Instalación de Win32-OpenSSH

El primer paso para usar SSH con Windows es instalar el Win32-OpenSSH servicio en el host de Windows. Microsoft ofrece una forma de instalar Win32-OpenSSH a través de una capacidad de Windows, pero actualmente la versión que se instala a través de este proceso es demasiado antigua para trabajar con Ansible. Instalar Win32-OpenSSH para usar con Ansible, seleccione una de estas tres opciones de instalación:

• Instale manualmente el servicio, siguiendo las instrucciones de instalación de Microsoft.

• Instala el openssh paquete con Chocolatey:

  choco install --package-parameters=/SSHServerFeature openssh
  

• Usar win_chocolatey para instalar el servicio:

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

• Utilice un rol de Ansible Galaxy existente como 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

Nota

Win32-OpenSSH sigue siendo un producto beta y se actualiza constantemente para incluir nuevas funciones y correcciones de errores. Si está utilizando SSH como una opción de conexión para Windows, se recomienda encarecidamente que instale la última versión de uno de los 3 métodos anteriores.

Configuración del shell Win32-OpenSSH

Por defecto Win32-OpenSSH utilizará cmd.exe como un caparazón. Para configurar un shell diferente, use una tarea de Ansible para definir la configuración del registro:

-name: set the default shell to PowerShell
  win_regedit:path: HKLM:SOFTWAREOpenSSH
    name: DefaultShell
    data: C:WindowsSystem32WindowsPowerShellv1.0powershell.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:SOFTWAREOpenSSH
    name: DefaultShell
    state: absent

Autenticación Win32-OpenSSH

La autenticación Win32-OpenSSH con Windows es similar a la autenticación SSH en hosts Unix / Linux. Puede usar una contraseña de texto sin formato o autenticación de clave pública SSH, agregar claves públicas a un authorized_key archivo en el .ssh carpeta del directorio del perfil del usuario, y configure el servicio usando el sshd_config archivo utilizado por el servicio SSH como lo haría en un host Unix / Linux.

Al usar la autenticación de clave SSH con Ansible, la sesión remota no tendrá acceso a las credenciales del usuario y fallará al intentar acceder a un recurso de red. Esto también se conoce como problema de delegación de credenciales o de doble salto. Hay dos formas de solucionar este problema:

• Utilice la autenticación de contraseña de texto sin formato configurando ansible_password
• Usar become en la tarea con las credenciales del usuario que necesita acceso al recurso remoto

Configuración de Ansible para SSH en Windows

Para configurar Ansible para usar SSH para hosts de Windows, debe establecer dos variables de conexión:

• colocar ansible_connection para ssh
• colocar ansible_shell_type para cmd o powershell

los ansible_shell_type variable debe reflejar el DefaultShell configurado en el host de Windows. Ajustado a cmd para el shell predeterminado o establecido en powershell Si el DefaultShell se ha cambiado a PowerShell.

Problemas conocidos con SSH en Windows

El uso de SSH con Windows es experimental y esperamos descubrir más problemas. Aquí están los conocidos:

• Win32-OpenSSH versiones anteriores a v7.9.0.0p1-Beta no trabajas cuando powershell es el tipo de concha
• Si bien SCP debería funcionar, SFTP es el mecanismo de transferencia de archivos SSH recomendado para usar al copiar o recuperar un archivo

Ver también

Introducción a los libros de jugadas

Introducción a los libros de jugadas

Consejos y trucos

Consejos y trucos para libros de jugadas

Lista de módulos de Windows

Lista de módulos específicos de Windows, todos implementados en PowerShell

Lista de correo de usuarios

¿Tengo una pregunta? ¡Pasa por el grupo de google!

irc.freenode.net

Canal de chat de IRC #ansible