Teleport interactive session termination classification for SSH, Kubernetes and Database access

Direct answer

Teleport does not consistently emit a distinct audit event type that separates client-initiated cancellation from server-enforced idle or connection timeouts across SSH, Kubernetes, and Database access. In current deployments, interactive session termination is generally recorded as a generic session end event, with the underlying cause inferred from the transport closure rather than exposed as a structured, protocol-independent classification field.

Confirmed behavior versus likely explanation

Confirmed across protocols: session recordings finalize when the server detects the transport close, whether that close originates from the client or from a timeout. Audit logs record the timestamp of termination. The specific reason for termination—such as “user cancelled” versus “idle timeout”—is not uniformly represented as a discrete field in the audit event for all three access types.

Likely explanation: because Teleport proxies interactive sessions at the transport layer, a client-initiated cancel (for example, closing an SSH terminal or killing a port-forward process) and a server-enforced timeout both result in the same TCP-level FIN or RST. The proxy interprets both as a session termination and writes an end event. Unless the specific protocol handler explicitly annotates the event with a reason code, the audit log entry remains generic.

Protocol-specific considerations

• SSH: Server-side idle_timeout and client inactivity lead to transport closure. A user typing exit or closing the terminal also closes the transport. Both paths converge on the same session end event unless the SSH server explicitly labels the reason.
• Kubernetes exec and port-forward: These streams are multiplexed through the Teleport Proxy. Termination is recorded when the stream closes, but the audit event may not distinguish between the user closing kubectl port-forward and the Kubernetes API server or proxy enforcing a limit.
• Database proxy: Connection timeouts configured on the database protocol or the Teleport Proxy cause termination. The resulting audit event is typically a session end without a granular reason code that separates client cancellation from protocol timeout.

Session recording completion

Session recording finalization is triggered by the server detecting the transport closure. This applies uniformly whether the closure is client-initiated or timeout-driven. In practice, recording completion can lag the actual transport close by a short interval because the server flushes buffered session data before sealing the recording.

Practical verification

To confirm behavior in your environment, inspect the audit log for session end events after deliberately triggering both a client cancel and a timeout. Search your Teleport auth server audit log for session termination entries; the event type to look for is session.end:

grep '"type":"session.end"' /var/lib/teleport/log/audit.log

Compare the fields present in the end event after a manual exit versus an idle timeout. If the event lacks a reason or termination cause field, the classification is implicit rather than explicit.

For a scoped test, create a role with a short idle timeout, apply it to a test user, and observe whether the resulting audit entry differs from a client-initiated close. Avoid changing production roles during this test.

Missing diagnostic

Which Teleport version and deployment topology are you using? The exact audit event schema and whether recent versions introduced explicit termination reason fields depend heavily on the version and whether you are running self-hosted or Teleport Cloud.