Windows uses WinRM as the transport protocol. WinRM supports a wide range of
authentication options. The closet option to SSH keys is to use the certificate
authentication option which maps an X509 certificate to a local user.

The way that these certificates are generated and mapped to a user is different
from the SSH implementation; consult the Windows Remote Management documentation for
more information.

Ansible executes commands through WinRM. These processes are different from
running a command locally in these ways:

Unless using an authentication option like CredSSP or Kerberos with
credential delegation, the WinRM process does not have the ability to
delegate the user’s credentials to a network resource, causing AccessisDenied errors.

All processes run under WinRM are in a non-interactive session. Applications
that require an interactive session will not work.

When running through WinRM, Windows restricts access to internal Windows
APIs like the Windows Update API and DPAPI, which some installers and
programs rely on.

Some ways to bypass these restrictions are to:

Use become, which runs a command as it would when run locally. This will
bypass most WinRM restrictions, as Windows is unaware the process is running
under WinRM when become is used. See the Understanding Privilege Escalation documentation for more
information.

Use a scheduled task, which can be created with win_scheduled_task. Like
become, it will bypass all WinRM restrictions, but it can only be used to run
commands, not modules.

Use win_psexec to run a command on the host. PSExec does not use WinRM
and so will bypass any of the restrictions.

To access network resources without any of these workarounds, an
authentication option that supports credential delegation can be used. Both
CredSSP and Kerberos with credential delegation enabled can support this.

Most of the Ansible modules in Ansible Core are written for a combination of
Linux/Unix machines and arbitrary web services. These modules are written in
Python and most of them do not work on Windows.

Because of this, there are dedicated Windows modules that are written in
PowerShell and are meant to be run on Windows hosts. A list of these modules
can be found here.

In addition, the following Ansible Core modules/action-plugins work with Windows:

No, the WinRM connection protocol is set to use PowerShell modules, so Python
modules will not work. A way to bypass this issue to use
delegate_to:localhost to run a Python module on the Ansible controller.
This is useful if during a playbook, an external service needs to be contacted
and there is no equivalent Windows module available.

Microsoft has announced and is developing a fork of OpenSSH for Windows that
allows remote manage of Windows servers through the SSH protocol instead of
WinRM. While this can be installed and used right now for normal SSH clients,
it is still in beta from Microsoft and the required functionality has not been
developed within Ansible yet.

There are future plans on adding this feature and this page will be updated
once more information can be shared.

When trying to connect to a Windows host and the output error indicates that
SSH was used, then this is an indication that the connection vars are not set
properly or the host is not inheriting them correctly.

Make sure ansible_connection:winrm is set in the inventory for the Windows
host.

When the Ansible controller is running on Python 2.7.9+ or an older version of Python that
has backported SSLContext (like Python 2.7.5 on RHEL 7), the controller will attempt to
validate the certificate WinRM is using for an HTTPS connection. If the
certificate cannot be validated (such as in the case of a self signed cert), it will
fail the verification process.

To ignore certificate validation, add
ansible_winrm_server_cert_validation:ignore to inventory for the Windows
host.