SSH session stays active after client request timeout in Teleport

Question

Symptom
When a Teleport client cancels an SSH connection request—either by exceeding a context deadline or by explicit cancellation—the SSH session on the server may remain active until the server‑side idle timeout expires.
Goal
Determine whether Teleport provides a mechanism to terminate an established SSH session immediately when the client‑side request context is cancelled, without waiting for the idle timeout.
Constraints and Uncertainty
The current behavior relies on the `idle_timeout` setting; there is no documented setting that forces immediate session closure on RPC context cancellation. It is unclear if lowering `idle_timeout` to zero achieves instant termination or disables the timeout altogether, and whether the client can send a signal that the server honors instantly upon request cancellation.

Is there a server‑side configuration that causes the SSH session to be closed as soon as the associated RPC context is cancelled?
Does setting `idle_timeout` to zero result in immediate session termination, or does it disable the timeout mechanism?
Can the client trigger an immediate SSH disconnect (e.g., by sending a SSH_MSG_DISCONNECT) that the server honors right after request cancellation?

Tasadduq Burney · Answer

Direct answerNo. Teleport does not expose a documented server-side setting that tears down an established SSH session the moment a client RPC context is cancelled. Setting idle_timeout to 0 disables the idle-timeout mechanism entirely; it does not cause immediate termination. A client can force an instant close by sending SSH_MSG_DISCONNECT, but that is a client-initiated action, not an automatic server reaction to context cancellation.Likely explanation versus confirmed behaviorConfirmed: idle_timeout: 0 removes the safety net, allowing orphaned sessions to persist indefinitely. Confirmed: the Teleport SSH server honors a standard SSH_MSG_DISCONNECT and closes the session immediately.Likely explanation: cancelling a client-side RPC context does not always synchronously propagate a transport-level close to the target node. The server therefore keeps the session until the idle timeout or a TCP keepalive expires. Because proxy connection handling and session multiplexing have changed across Teleport versions, the exact propagation behavior should be verified against your specific release.Steps for this caseInspect the node's teleport.yaml for ssh_service.idle_timeout. If it is 0, set a small positive duration such as 1m to bound orphaned sessions.Compare the session end timestamp in Teleport audit logs with the client cancellation time to quantify the actual delay.Run tsh or ssh with debug logging to determine whether an SSH_MSG_DISCONNECT is transmitted when the context is cancelled.Review Teleport proxy and node logs for connection teardown events immediately after cancellation.Missing diagnostic detailDoes your client send an SSH_MSG_DISCONNECT before cancelling the RPC context, or does it cancel the context without a transport-level close? If the disconnect is already sent, the issue is likely version-specific propagation; if not, the immediate remedy is client-side rather than server configuration.

SSH session stays active after client request timeout in Teleport

Symptom

Goal

Constraints and Uncertainty

1 answer

Direct answer

Likely explanation versus confirmed behavior

Steps for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments