SSH session tokens never expire

[pimlock]

Summary

SSH session tokens are UUIDs generated when a client calls CreateSshSession. The token is stored with sandbox id, creation time, and a revoked flag. There is no expiry time or TTL. The only way to invalidate a token is to call RevokeSshSession, which sets revoked = true. If a token is stolen or leaked, it remains valid for SSH access to the sandbox until someone explicitly revokes it.

Source Code

• Session creation in crates/navigator-server/src/grpc.rs in create_ssh_session (lines 576-628): a new UUID is generated (line 597), and an SshSession is built with revoked: false and no expiry field (lines 598-605), then persisted via store.put_message.
• The proto and store model for SshSession include created_at_ms and revoked but no expires_at or similar. Revocation is in revoke_ssh_session (lines 689-716).

---

Originally by @drew on 2026-02-19T08:59:15.075-08:00

[johntmyers]

🔒 security-review-agent

Security Review

Determination: Legitimate concern

Summary

SSH session tokens (SshSession) are UUIDv4 strings with no expiry or TTL. Once created, they remain valid indefinitely until explicitly revoked via RevokeSshSession. This is compounded by the absence of session cleanup on sandbox deletion and no garbage collection of stale session records. While mandatory mTLS on the gateway significantly limits the attack surface, the lack of token expiry violates the principle of least privilege in time and creates unnecessary risk if mTLS credentials are compromised or if the threat model evolves.

Severity Assessment

• Impact: High — a leaked token grants persistent SSH access to a sandbox (shell, port-forwarding) with no time-bound limit, effectively equivalent to permanent credentials.
• Exploitability: Medium — exploitation requires possession of both a valid SSH session token AND valid mTLS client credentials. The mTLS requirement is a strong mitigating control, but within that trust boundary (e.g., a compromised CI runner, leaked client cert, or insider threat), a stolen token is trivially usable from any IP with no usage limits.
• Affected components:
  • crates/navigator-server/src/grpc.rs — create_ssh_session (lines 789-818), revoke_ssh_session (lines 878-906)
  • crates/navigator-server/src/ssh_tunnel.rs — tunnel_handler validation (lines 50-61) lacks expiry check
  • proto/navigator.proto — SshSession message (lines 234-252) has no expires_at field
  • crates/navigator-server/src/grpc.rs — delete_sandbox (lines 515-576) does not revoke associated sessions

Attack Scenario

Step-by-step from the attacker's perspective:

1. Attacker obtains a valid SSH session token (e.g., from logs, a shared environment, a compromised workstation, or a CI pipeline artifact) along with mTLS credentials (which may be shared across a team or org).
2. Attacker issues an HTTP CONNECT to /connect/ssh on the gateway with headers X-Sandbox-Id and X-Sandbox-Token, using valid mTLS client cert.
3. The gateway validates only that the token exists, is not revoked, and the sandbox is Ready — no expiry check, no IP binding, no usage counter.
4. Attacker gets a fully authenticated SSH tunnel to the target sandbox with shell access and loopback port-forwarding, usable indefinitely and from unlimited concurrent connections.
5. Even if the legitimate user "finishes" their work and forgets to revoke the session, the token remains valid as long as the sandbox exists.

Remediation Plan

1. Add expires_at_ms field to SshSession proto (proto/navigator.proto). Add an int64 expires_at_ms field to the SshSession message.

2. Set TTL on session creation (crates/navigator-server/src/grpc.rs, create_ssh_session). Add a configurable ssh_session_ttl_secs to the server config (suggest default of 24 hours). Set expires_at_ms = created_at_ms + (ttl * 1000) at creation time.

3. Check expiry during tunnel validation (crates/navigator-server/src/ssh_tunnel.rs, tunnel_handler). After the existing revoked check at line 56, add: if session.expires_at_ms > 0 && current_time_ms() > session.expires_at_ms { return UNAUTHORIZED }.

4. Revoke sessions on sandbox deletion (crates/navigator-server/src/grpc.rs, delete_sandbox). Before deleting the sandbox record, query all SshSession objects with matching sandbox_id and either revoke or delete them.

5. Add a background session reaper (new task in server startup). Periodically scan for sessions where expires_at_ms < now or whose sandbox_id no longer exists, and delete them from the store. This prevents unbounded database growth.

Additional Notes

• mTLS is a strong mitigating control — this issue is not exploitable from the open internet. However, mTLS certs in this system also never expire (crates/navigator-bootstrap/src/pki.rs line 36), which compounds the risk if the broader trust boundary is breached.
• Existing connection persistence — revoking or expiring a token only prevents new tunnels. Active copy_bidirectional connections (ssh_tunnel.rs line 100) continue until naturally closed. Consider adding a cancellation token mechanism for active tunnels if stronger revocation semantics are needed in the future.
• Unlimited concurrent reuse — a single token can establish unlimited parallel SSH connections. Consider adding a max_connections field or per-token connection counter as a follow-up hardening measure.
• No rate limiting — there are no rate limits on session creation or connection attempts. mTLS limits the caller pool, but within that pool, abuse is unconstrained.

[johntmyers]

🔧 security-fix-agent

Implementation Plan

Problem Statement

SSH session tokens are UUIDv4 strings with no expiry. Once created via CreateSshSession, they remain valid indefinitely until explicitly revoked. Additionally, there is no cleanup of sessions when sandboxes are deleted, no garbage collection of stale records, and no limit on concurrent connections per token.

Goals

1. Add TTL-based expiry to SSH session tokens without breaking any existing UX flows
2. Limit concurrent connections per token to 10 (also serves as rate limiting mitigation)
3. Revoke/delete SSH sessions when their sandbox is deleted
4. Add a background reaper for expired and orphaned sessions

Non-Goals (Explicit)

• Connection persistence changes: existing active tunnels are not terminated on revocation or expiry. The copy_bidirectional pattern in ssh_tunnel.rs:200 continues until the connection drops naturally. No changes here.
• Per-sandbox session count limits (future work)
• IP binding or client fingerprinting (future work)

---

Why TTL Will Not Break UX

This is the most important design question. The answer comes from how the CLI actually uses SSH sessions.

How Sessions Are Created Today

Every CLI command that uses SSH calls ssh_session_config() (crates/navigator-cli/src/ssh.rs:31), which calls CreateSshSession to get a fresh token. This happens on every invocation:

CLI Command	Code Path	Creates Fresh Session?
nemoclaw sandbox connect	sandbox_connect() → ssh_session_config()	Yes, every time
nemoclaw sandbox exec	sandbox_exec() → ssh_session_config()	Yes, every time
nemoclaw sandbox forward	sandbox_forward() → ssh_session_config()	Yes, every time
nemoclaw sandbox sync-up	sandbox_sync_up() → ssh_session_config()	Yes, every time
nemoclaw sandbox sync-down	sandbox_sync_down() → ssh_session_config()	Yes, every time
SSH config ProxyCommand	sandbox_ssh_proxy_by_name() → ssh_session_config()	Yes, every time

No CLI path reuses an existing token. The token is created, used to establish one SSH connection, and then never referenced again. The ssh_session_config function at ssh.rs:31 always calls client.create_ssh_session(...) unconditionally.

Why a 24h TTL Is Safe

Given that every CLI invocation creates a fresh session:

1. Interactive connect/exec: User runs command, fresh token is created, SSH session lasts minutes to hours. A 24h TTL is orders of magnitude longer than any interactive session.

2. Port forwarding (forward --background): This is the longest-lived use case. A background SSH process holds a single connection open indefinitely. But the TTL only gates new connections via the token — the existing tunnel (already established via copy_bidirectional) continues regardless of token expiry. The token is never reused after the initial CONNECT.

3. ProxyCommand via ~/.ssh/config: sandbox_ssh_proxy_by_name creates a fresh session on every SSH invocation (line 552-561). Each ssh sandbox command gets a new token. TTL is irrelevant here.

4. File sync operations: sync-up and sync-down are short-lived (seconds). Fresh token each time.

In every case, the token is used exactly once to establish a connection, and then the connection outlives the token. TTL expiry would only prevent someone from reusing an old token to establish a new connection — which is exactly the security property we want.

Edge Case: SDK/API Users

External SDK or API users who call CreateSshSession directly and store the token for later use would be affected by TTL. This is the intended behavior — tokens should not be long-lived credentials. The CreateSshSessionResponse will include expires_at_ms so clients can implement refresh logic if needed.

---

Implementation Details

Change 1: Proto Schema — Add expires_at_ms to SshSession

File: proto/navigator.proto (lines 234-252)

Add field 7 to the SshSession message:

message SshSession {
  string id = 1;
  string sandbox_id = 2;
  string token = 3;
  int64 created_at_ms = 4;
  bool revoked = 5;
  string name = 6;
  // Expiry timestamp in milliseconds since epoch. 0 means no expiry.
  int64 expires_at_ms = 7;
}

Add expires_at_ms to CreateSshSessionResponse so clients know the token's lifetime:

message CreateSshSessionResponse {
  string sandbox_id = 1;
  string token = 2;
  string gateway_host = 3;
  uint32 gateway_port = 4;
  string gateway_scheme = 5;
  string connect_path = 6;
  string host_key_fingerprint = 7;
  // Expiry timestamp in milliseconds since epoch. 0 means no expiry.
  int64 expires_at_ms = 8;
}

Proto field addition is backward-compatible — existing clients will see 0 (no expiry) for the new field, and old session records without the field will decode with expires_at_ms = 0, which the validation code treats as "no expiry" (see Change 4).

Change 2: Server Config — Add ssh_session_ttl_secs

File: crates/navigator-core/src/config.rs

Add a new config field with a 24-hour default:

/// TTL for SSH session tokens, in seconds. 0 disables expiry.
#[serde(default = "default_ssh_session_ttl_secs")]
pub ssh_session_ttl_secs: u64,

const fn default_ssh_session_ttl_secs() -> u64 {
    86400 // 24 hours
}

Add the corresponding builder method and wire it into Config::new().

Change 3: Session Creation — Set expires_at_ms

File: crates/navigator-server/src/grpc.rs (lines 789-818)

In create_ssh_session, compute and set the expiry:

let now_ms = current_time_ms()...;
let expires_at_ms = if self.state.config.ssh_session_ttl_secs > 0 {
    now_ms + (self.state.config.ssh_session_ttl_secs as i64 * 1000)
} else {
    0 // no expiry
};

let session = SshSession {
    id: token.clone(),
    sandbox_id: req.sandbox_id.clone(),
    token: token.clone(),
    created_at_ms: now_ms,
    revoked: false,
    name: generate_name(),
    expires_at_ms,
};

Include expires_at_ms in the CreateSshSessionResponse.

Change 4: Tunnel Validation — Check Expiry

File: crates/navigator-server/src/ssh_tunnel.rs (lines 59-61)

After the existing revoked/sandbox_id check, add expiry validation:

if session.revoked || session.sandbox_id != sandbox_id {
    return StatusCode::UNAUTHORIZED.into_response();
}

// Check token expiry (0 means no expiry for backward compatibility).
if session.expires_at_ms > 0 {
    let now_ms = current_time_ms().unwrap_or(0);
    if now_ms > session.expires_at_ms {
        return StatusCode::UNAUTHORIZED.into_response();
    }
}

Backward-compatible: sessions created before this change have expires_at_ms = 0 and skip the check.

Change 5: Concurrent Connection Limit (Max 10)

Files:

• crates/navigator-server/src/lib.rs — add field to ServerState
• crates/navigator-server/src/ssh_tunnel.rs — enforce limit

Add an in-memory connection counter to ServerState:

use std::collections::HashMap;
use std::sync::Mutex;

pub struct ServerState {
    // ... existing fields ...

    /// Active SSH tunnel connection counts per session token.
    pub ssh_connection_counts: Mutex<HashMap<String, u32>>,
}

Mutex<HashMap> is preferred over DashMap to avoid a new dependency. The critical section is trivially small (increment/decrement an integer), and contention will be negligible.

In ssh_connect, after token validation and before spawning the tunnel task:

const MAX_SSH_CONNECTIONS_PER_TOKEN: u32 = 10;

{
    let mut counts = state.ssh_connection_counts.lock().unwrap();
    let count = counts.entry(token.clone()).or_insert(0);
    if *count >= MAX_SSH_CONNECTIONS_PER_TOKEN {
        return StatusCode::TOO_MANY_REQUESTS.into_response();
    }
    *count += 1;
}

In the spawned tunnel task, decrement on completion (regardless of success/failure):

// Decrement on exit:
let mut counts = state_clone.ssh_connection_counts.lock().unwrap();
if let Some(count) = counts.get_mut(&token_clone) {
    *count = count.saturating_sub(1);
    if *count == 0 {
        counts.remove(&token_clone);
    }
}

This also serves as rate limiting mitigation: a stolen token is capped at 10 concurrent connections, bounding the damage from any single compromised credential. Combined with mTLS requirements, this makes abuse impractical without further rate limiting infrastructure.

Change 6: Revoke Sessions on Sandbox Deletion

File: crates/navigator-server/src/grpc.rs (lines 515-577)

In delete_sandbox, after setting the sandbox phase to Deleting and before the k8s delete call, find and delete all SSH sessions for this sandbox:

// Clean up SSH sessions for this sandbox.
let sessions = self
    .state
    .store
    .list(SshSession::object_type(), 1000, 0)
    .await
    .unwrap_or_default();

for record in sessions {
    if let Ok(session) = SshSession::decode(record.payload.as_slice()) {
        if session.sandbox_id == id {
            if let Err(e) = self
                .state
                .store
                .delete(SshSession::object_type(), &session.id)
                .await
            {
                warn!(session_id = %session.id, error = %e,
                    "Failed to delete SSH session during sandbox cleanup");
            }
        }
    }
}

Future optimization note: The generic objects table doesn't support filtering by payload fields. The list-all + filter-in-code approach is acceptable because SSH session counts are low (typically single digits per sandbox).

Change 7: Background Session Reaper

File: crates/navigator-server/src/ssh_tunnel.rs (new function)

Add a background task that periodically cleans up expired and revoked sessions:

pub fn spawn_session_reaper(store: Arc<Store>, interval: Duration) {
    tokio::spawn(async move {
        tokio::time::sleep(interval).await;
        loop {
            if let Err(e) = reap_expired_sessions(&store).await {
                warn!(error = %e, "SSH session reaper sweep failed");
            }
            tokio::time::sleep(interval).await;
        }
    });
}

Launch from run_server() in lib.rs alongside the existing spawn_store_reconciler:

ssh_tunnel::spawn_session_reaper(state.store.clone(), Duration::from_secs(3600));

Reaper interval of 1 hour is sufficient — the tunnel validation check enforces expiry in real time; the reaper just prevents unbounded database growth.

---

File Change Summary

File	Change
proto/navigator.proto	Add expires_at_ms to SshSession (field 7) and CreateSshSessionResponse (field 8)
crates/navigator-core/src/config.rs	Add ssh_session_ttl_secs config field (default 86400)
crates/navigator-server/src/grpc.rs	Set expiry on creation, include in response, clean up sessions on sandbox delete
crates/navigator-server/src/ssh_tunnel.rs	Check expiry in tunnel handler, add connection counter logic, add session reaper
crates/navigator-server/src/lib.rs	Add ssh_connection_counts to ServerState, launch reaper

Test Plan

Unit Tests

1. Expiry check: mock session with expires_at_ms in the past → assert UNAUTHORIZED. Future expiry → assert passes.
2. Zero expiry backward compat: session with expires_at_ms = 0 → assert passes (no expiry enforced).
3. Connection counter: increment to 10 → assert 11th returns TOO_MANY_REQUESTS. Decrement one → assert 11th succeeds.
4. Session reaper: create expired + non-expired sessions → run reaper → assert only expired ones deleted.

Integration Tests

1. TTL enforcement: create session with 1-second TTL, wait 2 seconds, attempt CONNECT → expect UNAUTHORIZED.
2. Sandbox delete cleans sessions: create sandbox + SSH session, delete sandbox → verify session record gone.
3. Concurrent connection limit: establish 10 CONNECT requests → verify 11th gets 429.

Rollout / Backward Compatibility

• Proto changes are additive (new field numbers). Existing clients are unaffected.
• Existing sessions in the database decode with expires_at_ms = 0, treated as "no expiry". They continue to work and can still be manually revoked.
• Config default of 24h means no operator action required. Set to 0 to restore old behavior.
• The 10-connection limit is hardcoded for now. A config field can be added later if operators need to tune it.

[johntmyers]

🔧 security-fix-agent

Plan Revision: Per-Sandbox Connection Limit

The previous plan had a contradiction: Goal 2 limited concurrent connections per token, but Non-goal 2 excluded per-sandbox session limits. These are distinct concepts, but the gap between them allows bypass via token proliferation (create many tokens, each with 10 connections).

What Changed

Non-goal 2 is removed. Replaced with an additional per-sandbox concurrent connection limit.

The concurrent connection tracking in Change 5 now enforces two limits using the same in-memory counter:

Limit	Value	What It Prevents
Per-token	10 concurrent connections	Single leaked token from being over-used
Per-sandbox	20 concurrent connections	Bypass via creating many tokens for one sandbox

Why Per-Sandbox Connection Limit (Not Token Limit)

A per-sandbox token creation cap would break normal CLI usage. The CLI creates a fresh token on every command (ssh_session_config() calls CreateSshSession unconditionally). Tokens are not revoked when the connection closes — they linger until TTL expiry. A developer running 20 commands in a day would hit a token cap even though all prior connections are long gone.

A per-sandbox concurrent connection limit avoids this entirely: it counts only active tunnels (tracked in-memory), not stale session records.

Updated Change 5: Concurrent Connection Limits

Files:

• crates/navigator-server/src/lib.rs — add fields to ServerState
• crates/navigator-server/src/ssh_tunnel.rs — enforce both limits

Add two in-memory counters to ServerState:

pub struct ServerState {
    // ... existing fields ...

    /// Active SSH tunnel connections per session token.
    pub ssh_connections_by_token: Mutex<HashMap<String, u32>>,
    /// Active SSH tunnel connections per sandbox id.
    pub ssh_connections_by_sandbox: Mutex<HashMap<String, u32>>,
}

In ssh_connect, after token validation and before spawning the tunnel:

const MAX_CONNECTIONS_PER_TOKEN: u32 = 10;
const MAX_CONNECTIONS_PER_SANDBOX: u32 = 20;

// Check per-token limit.
{
    let mut counts = state.ssh_connections_by_token.lock().unwrap();
    let count = counts.entry(token.clone()).or_insert(0);
    if *count >= MAX_CONNECTIONS_PER_TOKEN {
        return StatusCode::TOO_MANY_REQUESTS.into_response();
    }
    *count += 1;
}

// Check per-sandbox limit.
{
    let mut counts = state.ssh_connections_by_sandbox.lock().unwrap();
    let count = counts.entry(sandbox_id.clone()).or_insert(0);
    if *count >= MAX_CONNECTIONS_PER_SANDBOX {
        // Roll back the per-token increment.
        let mut token_counts = state.ssh_connections_by_token.lock().unwrap();
        if let Some(c) = token_counts.get_mut(&token) {
            *c = c.saturating_sub(1);
            if *c == 0 { token_counts.remove(&token); }
        }
        return StatusCode::TOO_MANY_REQUESTS.into_response();
    }
    *count += 1;
}

On tunnel completion, decrement both counters.

Updated Non-Goals

• Connection persistence changes: no changes (unchanged)
• Per-sandbox session count limits → now a goal (per-sandbox connection limit of 20)
• IP binding or client fingerprinting (future work)

All other changes (1-4, 6-7) from the previous plan are unchanged.