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 😊

[thein3rovert]

Following up with additional diagnostics I ran directly on the Automation Remote appliance (SSH'd in and  tailed the adapter logs while triggering the workflow).

Confirmed findings:
1. The Unix/Linux SSH Command node has a hardcoded ~180 second (3 min) internal timeout that ignores the "Activity timeout" UI setting. I set the Activity timeout to 1800s, then 3600s — in both cases the adapter logged "Error Message: Activity timeout" at exactly 180 heartbeats (each heartbeat is 1 second):

2026-08-03T17:21:09Z terminal.ssh_command tag=8e969859
2026-08-03T17:24:09Z Error Message: Activity timeout. Last output: heartbeat 180 17:24:13...

2. The container is completely healthy at the moment of failure: no OOM, no restart, no CPU/memory spike. docker stats showed 1.49% CPU / 27 MiB memory during the run.

Please, i need update on this.

[Ed Novak - Cisco Workflows TME]

@thein3rovert This is clearly a bug in the adapter. I'll get a defect opened for this. I don't have a workaround or an ETA for a fix at this time.  Thank you for bringing this issue to my attention and for your very detailed analysis.

[thein3rovert]

Thanks again for the fast turnaround, really appreciate you confirming this.

[thein3rovert]

Hello  @Ed Novak - Cisco Workflows TME  , hope you're having a good day?

I'm following up to see whether there have been any updates on the SSH adapter issue raised in August.

The 180-second timeout is still a concern for our workflows, particularly those that require longer-running SSH commands over 180s. Could you please share whether a issue has been logged and if there is any update on a potential fix, workaround, or ETA?
Any update would be appreciated.

Thanks for your help.

[Ed Novak - Cisco Workflows TME]

@thein3rovert I'm well, I hope you are also. Thanks for following up. I can confirm that the team has an open defect to investigate and address the 180-second SSH adapter timeout issue. I’m checking with them for a status update, including any workaround or ETA. I don’t have a confirmed fix or ETA to share yet, but I’ll post an update here when I hear back.

[Ed Novak - Cisco Workflows TME]

@thein3rovert  Thanks for your patience. I confirmed with Engineering that this fix has been implemented and is currently in testing. It isn’t included in the current Remote version; it will be included in version 6.74, which is expected to be available within the next four weeks.

Neither the OVA Remote nor the container Remote updates automatically. Once 6.74 is released, you’ll need to download and redeploy the new Remote version to get the fix.