Checkout the Ansible Automation for Windows guides.
WinRM vs OpenSSH – Pros & Cons
Ansible supports managing Windows hosts using two connection types:
- WinRM (Windows Remote Management) – default and traditional method.
- OpenSSH – newer method, especially post-Windows 10 / Server 2019.
WinRM (Default)
✔️ Pros
| Pros | Description |
|---|---|
| ✅ Native Support | Built-in to Windows OS; enabled and configured on most enterprise systems. |
| ✅ Full Module Compatibility | All Ansible Windows modules are fully tested with WinRM. |
| ✅ PowerShell-centric | Designed for PowerShell automation and WinRM natively uses it. |
| ✅ Kerberos & Domain Integration | Supports AD/Kerberos for seamless authentication in domain environments. |
| ✅ Mature & Documented | WinRM has been the default for years; tons of docs, blogs, support. |
❌ Cons
| Cons | Description |
|---|---|
| ❌ Complex Configuration | Requires setting up listeners, ports (5985/5986), HTTPS, certificates, etc. |
| ❌ Firewall Hassles | Extra firewall rules needed; port 5986 often blocked by security policies. |
| ❌ Slow Performance | Known to be slower than SSH in many operations. |
| ❌ SSL Certificate Setup | Secure mode needs signed certs, which is painful in many orgs. |
| ❌ Occasional Encoding Issues | Especially with special characters or non-English content. |
| ❌ No Agent Forwarding | Unlike SSH, WinRM lacks native support for agent/key forwarding. |
🆕 OpenSSH
✔️ Pros
| Pros | Description |
|---|---|
| ✅ Simpler Setup | Just install OpenSSH, open port 22, and you’re good to go. |
| ✅ Uses Existing SSH Workflow | Easy integration for teams already using SSH in Linux/macOS. |
| ✅ Better Performance | Usually faster than WinRM in most tasks. |
| ✅ Standard Port | Uses port 22, often already open in mixed environments. |
| ✅ Easier Key Management | Supports SSH keys (no need for certs or complex auth). |
| ✅ Works with SSH Agent | Supports ssh-agent and agent forwarding. |
❌ Cons
| Cons | Description |
|---|---|
| ❌ Not Fully Supported | Some Ansible Windows modules may not work or behave differently. |
| ❌ Requires Extra Setup | OpenSSH is not enabled by default on all Windows versions (esp. older). |
| ❌ Limited AD/Kerberos | No built-in support for domain/Kerberos auth like WinRM. |
| ❌ Troubleshooting May Be Harder | Errors are often lower-level and less descriptive. |
| ❌ Inconsistent Shell Experience | Some PowerShell-specific commands may behave oddly under SSH shell. |
💡 Use Case Scenarios
| Scenario | Recommendation |
|---|---|
| Domain-joined environment | WinRM (for Kerberos & seamless integration) |
| Hybrid/mixed Linux-Windows infra | OpenSSH (for consistency and ease) |
| Security restrictions on custom ports | OpenSSH (uses port 22) |
| Need speed and simplicity | OpenSSH |
| Complex legacy systems with existing WinRM setup | WinRM |
| AD authentication is mandatory | WinRM |
📝 Summary Recommendation for Proposal
Default Option: Start with WinRM if compatibility and AD integration are top priority, especially for large enterprise or domain-joined machines.
Alternative Option: Consider OpenSSH if:
- New environment with fewer legacy dependencies.
- You’re already using SSH keys.
- You want faster and easier setup.
- The infrastructure team prefers standard SSH tooling.
Long-Term Plan: Evaluate hybrid usage, or standardize on OpenSSH as it becomes more mature and broadly supported.
📋 Proposal Add-on: Migration/Decision Factors
If switching between connection methods, consider:
- Compatibility check for required modules.
- Authentication needs (Kerberos vs SSH keys).
- Security team policies (ports, protocols).
- User familiarity (PowerShell vs bash-like environments).
- Automation tools and their SSH/WinRM compatibility.
CredSSP
Enable CredSSP
Error: “credssp: Server did not response with a CredSSP token after step TLS Handshake - actual ‘’”,
ansible_winrm_credssp_disable_tlsv1_2