"Connect Timed Out" on Remote Script Execution

[drew mack]

I'm using RunDeck 3.3.10 on a server running Red Hat Enterprise Linux 7.9 in conjunction with RunDeck WinRM 1.3.8 and RunDeck CopyFile Plugin 3.3.10 in attempt to execute powershell scripts on a remote Windows host (Server 2019).

The issue I'm encountering is RunDeck being apparently unable to create and execute copies of the scripts on the remote host. Command node steps will execute on the remote host and return as normal, but inline and referenced scripts do not execute properly. The debug output shows:

[overthere-winrm:<windows host>] ConnectionOptions[
connectionTimeoutMillis --> 28800000

winrmEnableHttps --> false

winrmKerberosDebug --> false

address --> <windows host>

winrmKerberosUseHttpSpn --> false

os --> WINDOWS

winrmKerberosAddPortToSpn --> false

file-copy-destination-dir --> null

connectionType --> WINRM_INTERNAL

password --> ********

winrmKerberosTicketCache --> false

port --> 5985

winrmTimeout --> PT28800.000S

username --> <username> ]

followed immediately by

com.xebialabs.overthere.RuntimeIOException: java.net.SocketTimeoutException: connect timed out 

--- huge stack trace ---

Caused by: java.net.SocketTimeoutException: connect timed out

--- more stack trace ---

[overthere-winrm:<windows host>] failed: java.net.SocketTimeoutException: connect timed out

every time. I have tried powershell and python scripts and they both give the same error.  I have WinRM configured as such on the host that RunDeck is connecting to for this job:

Config
    MaxEnvelopeSizekb = 500
    MaxTimeoutms = 300000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts = <rundeck host>
    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 = true
        Auth
            Basic = true
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            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

The user account that RunDeck uses for this job is an administrator on the Windows server. I have been at this for a while with no luck solving the problem so far, so I figured I would ask here to see if someone has seen something similar— have you?

Cheers!
Drew Mack

[rac...@rundeck.com]

Hi Drew,

Could you try with the PyWinRM plugin (out of the box with Rundeck 3.3.10, easiest to configure and in active development) instead of the old Overthere WinRM plugin?

Here you can check the requirements, here the configuration, and here a basic windows node definition example.

Regards!

[drew mack]

I have gone ahead and started on configuring my environment for using PyWinRM instead of overthere. I'm not done, but testing what I've been able to so far looks optimistic! I will update this thread when I do manage to get everything configured properly for using PyWinRM. Thanks for the speedy reply!