Closed sandroLuk closed 2 years ago
It seems that the issue affects only certificate login. I made a test with basic auth and it works there. But i still looking for a a solution for the certificate method.
The ECONNRESET
is a sign that the remote peer had completely shut down the connection for some reason. This can be due to many reasons like:
Unfortunately the server doesn't really indicate what goes wrong, it just kills the connection leading to what you see here. The fact that you said that this is happening only with certificate
auth would lead me to think that there's a problem with the server trying to process the certificate offered by the client.
Unfortunately from an Ansible perspective there's not much we can do. What I recommend is to enable debug logging for SChannel on the Windows host https://docs.microsoft.com/en-us/troubleshoot/developer/webapps/iis/health-diagnostic-performance/enable-schannel-event-logging. This will hopefuly have Windows log events on the TLS handshake process and potentially indicate why it rejected what the client was sending. You could also look into the WinRM operational logs to try and see if it's logging any errors that might be helpful https://devblogs.microsoft.com/scripting/troubleshoot-winrm-with-powershellpart-1/.
Hi @jborean93, thanks fot the hints, i will check if i can find something.
Have you tested by yourself to login on a win 2022 server via a certificate login and has it worked for you? I'm using the powershell script from the ansible repo (https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1) and it don't works for me on that version. Do you think i should create an issue for this on the main ansible git?
I can't say for sure whether I've tested against Server 2022 but I definitely have done it for 2019. The script mentioned just sets up the server with the listeners. It doesn't have anything to do with configuring the certificate mapping and it's not really something that belongs there.
The first step is figuring out why why certificate auth is failing. The first step is to verify that any other auth over HTTPS also works. Regardless of whether it does or does not work checking the SChannel logs to figure out why it may not be working.
Any updates here?
I have the same issue with the same error. So, on the 2019 and 2016 working fine, while trying 2022 getting this:
ansible [core 2.12.4]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/exor/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/exor/.local/lib/python3.8/site-packages/ansible
ansible collection location = /home/exor/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/local/bin/ansible
python version = 3.8.10 (default, Mar 15 2022, 12:22:08) [GCC 9.4.0]
jinja version = 2.10.1
libyaml = True
Using /etc/ansible/ansible.cfg as config file
setting up inventory plugins
host_list declined parsing /home/exor/12/hosts_new as it did not pass its verify_file() method
script declined parsing /home/exor/12/hosts_new as it did not pass its verify_file() method
auto declined parsing /home/exor/12/hosts_new as it did not pass its verify_file() method
Parsed /home/exor/12/hosts_new inventory source with ini plugin
Loading callback plugin minimal of type stdout, v2.0 from /home/exor/.local/lib/python3.8/site-packages/ansible/plugins/callback/minimal.py
Attempting to use 'default' callback.
Skipping callback 'default', as we already have a stdout callback.
Attempting to use 'junit' callback.
Attempting to use 'minimal' callback.
Skipping callback 'minimal', as we already have a stdout callback.
Attempting to use 'oneline' callback.
Skipping callback 'oneline', as we already have a stdout callback.
Attempting to use 'tree' callback.
META: ran handlers
redirecting (type: modules) ansible.builtin.win_ping to ansible.windows.win_ping
Loading collection ansible.windows from /home/exor/.local/lib/python3.8/site-packages/ansible_collections/ansible/windows
Using module file /home/exor/.local/lib/python3.8/site-packages/ansible_collections/ansible/windows/plugins/modules/win_ping.ps1
Pipelining is enabled.
<13.40.224.207> ESTABLISH WINRM CONNECTION FOR USER: Tteam on PORT 5986 TO 13.40.224.207
<13.40.224.207> WINRM CONNECT: transport=certificate endpoint=https://13.40.224.207:5986/wsman
<13.40.224.207> WINRM CONNECTION ERROR: ('Connection aborted.', OSError("(104, 'ECONNRESET')"))
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
httplib_response = self._make_request(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 421, in _make_request
six.raise_from(e, None)
File "
I've actually just recently came across this when trying to test out certificate auth in a GitHub Actions runner which runs on Server 2022.
Unfortunately I was not able to figure out the problem but it seems like the problem was due to some issue with TLS 1.3 (introduced with Server 2022) and certificate authentication. You can try to load the following functions from https://gist.github.com/jborean93/573695261ca50fb0142fa3f4a1a24fcd and run
$binding = Get-HttpSslCert -IPPort 0.0.0.0:5986
$binding | Remove-HttpSslCert
$binding | Add-HttpSslCert -DisableTls13 -DisableHttp2
When testing this in GHA it unfortunately didn't fix my problem for WinRM but testing cert auth in IIS did so you might have better luck. Also this was broken from a native PowerShell client and not just the Python libraries during my testing so not something Ansible/Python specific but some problem on the Windows stack.
Seems like the problem was in the default version of TLS which in Windows Server 2022 by default is 1.3 but ansbile/py libraries working with TLS 1.2 only So i've solved the problem by changing SCHANNEL registry which can be found by PATH Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\
I've added the parameter TLS 1.3 and two keys for Client and Server Folder wtih Powershell commands:
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -name 'Enabled' -value '0' –PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -name 'DisabledByDefault' -value '1' –PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'Enabled' -value '0' –PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'DisabledByDefault' -value '1' –PropertyType 'DWORD'
If you need tls 1.3 be enabled just delete the raws which add a rule for Enabled with Value 0 or replace it with Value 1.
When i made this, WINRM cert auth and remote Ansible commands started working fine.
Ultimately this seems to be a problem with the TLS stack on the Windows side. As the problem affects the native PowerShell client on Windows the issue needs to be raised with MS.
@jborean93 hm but isn't it on ansibles side to provide support for the newer TLS version 1.3 which seems to be the new standard? I mean when microsoft decides to accept only the newer protocol than that's not a microsoft bug but a security best practice and it would be good if ansible would support that. Or am i missing a point here?
Ansible supports TLS 1.3 just fine, the support comes from the builtin ssl lib in Python and I can confirm it works. What doesn’t work is certificate authentication as the server is closing the tunnel being established. When I was testing this I found that not even PowerShell itself can connect using certificate auth which tells me the problem exists on the server end.
If you can confirm that doing certificate auth from a Microsoft client, like PowerShell, works with the same server I’m happy to reopen this and investigate it more. The command to test this is:
Invoke-Command server { 'test' } -CertificateThumbprint $thumbprint
I believe the cert needs to be in the CurrentUser My/Personal store for it to find it by the thumbprint.
Also keep in mind the place where this all fits is in the native OpenSSL library that Python is calling. This is largely out of our control so it may not be something we can fix, or at least through an update from one of the winrm library.
For anyone else coming here and trying the above Powershell registry commands but are receiving errors: the dash in "-PropertyType" is a unicode dash (U+2013/EN DASH) not ASCII. Here's the same command but without the special symbols:
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Force
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -name 'Enabled' -value '0' -PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -name 'DisabledByDefault' -value '1' -PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'Enabled' -value '0' -PropertyType 'DWORD'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client' -name 'DisabledByDefault' -value '1' -PropertyType 'DWORD'
SUMMARY
I try to get ansible running to orchestrate a Windows Server 2022 host. The Server is fresh build from Windows Installer and only got the ansible connection-setup powershell script running on it. We use the same script for Windows Server 2019 and 2016 and it runs fine there. The connect is done by certificate.
When i try to connect with Ansible to the server i got that error:
ISSUE TYPE
COMPONENT NAME
Ansible basic functionality - Gather Facts (i guess its core?)
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
Ubuntu 20.04 Docker Container running on VM. Works without problems on hundreds of linux hosts and hundreds of windows host running Windows Server 2012R2, 2016 and 2019.
STEPS TO REPRODUCE
It can't connect already on initial facts gathering
EXPECTED RESULTS
Sucessful gathering facts
ACTUAL RESULTS