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?
