SSH Node Timeout on Long-Running Tasks

[thein3rovert]

I'm running into a problem with the Unix/Linux Execute SSH Command node when the remote command takes longer than a few minutes to complete.
Behavior observed:
- The node establishes an SSH session to a remote host and executes a long-running command.
- After ~5–10 minutes of low/no output from the command, the node's SSH session is silently terminated.
- The workflow either times out with no result, or hangs in "running" state indefinitely until the individual command timeout fires (e.g. 3600s).
- On the remote host, the command actually completes normally and produces expected output — but that output never reaches the workflow because the SSH connection is already gone.

Suspicion:
The SSH client used by the Unix/Linux SSH node doesn't appear to send TCP/SSH keep-alives during periods of low command output. Something in the connection path (Cisco-side, or an intermediate device the node's traffic traverses) is treating the idle SSH channel as dead and dropping the connection before the command finishes. If keep-alives were being sent, the connection would be held open regardless of command output timing.
What I'd like to confirm:
1. Does the Unix/Linux SSH node send TCP/SSH keep-alives on active sessions?
2. If so, is the interval configurable, and what's the default?
3. Is there a recommended pattern for running commands that legitimately take 10+ minutes to complete over this node without decoupling into a fire-and-forget model?

[Ed Novak - Cisco Workflows TME]

@thein3rovert I'll check, but I'm not aware of any keep-alive mechanism in the adapter to maintain an active connection while waiting for command output.  Is there any intermediate firewall/loadbalancer/NAT on the connection between your Automation Remote and the Target?

[thein3rovert]

@Ed Novak - Cisco Workflows TME Thanks for confirming.  We've done the test to rule out the issue.
We deployed a second server on the same subnet as our Automation Remote - no ACL, firewall, load balancer, or NAT anywhere in the path between them.

We ran a  "for i in {1..300}; do echo "heartbeat $i $(date +%T)"; sleep 1; done" script. 

The same script runs cleanly to completion when triggered from an interactive SSH terminal to the exact same target so this is specific to how the SSH node adapter behaves, not the script itself.

This strongly suggests a client-side behavior in the Unix/Linux SSH node adapter — the SSH session is being closed after a fixed duration regardless of activity or path.

Please help look into this 😊