Skip to content

feat(ssh): support Linux targets with a mode-aware connector #152

Description

@Tutitoos

Parent roadmap: #141. Extension after the eleven core phases; it does not block the Windows-target acceptance gate #150.

Objective

Support selected Linux SSH targets with the same Atenea SSH protocol, protected prompt handling and truthful mode capabilities.

Scope

Port the connector contract from #146/#147 to Linux accounts without copying Windows session, task scheduler or DPAPI assumptions. Verify the selected Linux user's identity, SSH/bootstrap prerequisites, Codex CLI/app version, working directory and user-session availability. Support hidden codex exec --ephemeral only where target-version testing confirms it remains absent from the app. Offer NEW/EXISTING visible chats only where the actual target client and user session support and render them; headless or unsupported visible modes must be shown as unavailable without a silent downgrade.

Install/update an account-owned versioned connector with trusted manifest, atomic activation, rollback, durable UUID/digest receipts and remote admission locks interoperable with #147. Protect persisted request/output payloads with user-owned permissions plus authenticated encryption using a documented Linux key source; private file permissions alone do not satisfy the encrypted-state contract. Handle missing/locked key store, logout, sleep, systemd user-service lifecycle and multiple graphical sessions explicitly. Never require root for routine prompt execution or assume linger grants an unlocked GUI or secret store.

Extend doctor, UI state and history to distinguish an SSH-reachable Linux host, installed connector, Codex availability, GUI readiness and mode-specific support. Preserve the local controller's trust, credential and audit boundaries. A Linux host with a hidden-only connector is reported as hidden-only, not fully ready for visible work.

Feasibility before implementation

Run a harmless mode/session canary before building the full connector, and record exactly which client and distribution support each route. Headless support is conditional on a reviewed encryption-key provisioning/unlock design; a GUI Secret Service cannot be assumed available through SSH. Document the selected protected key source, operator bootstrap, restart/recovery and unavailable-key behavior before persisting real requests. Do not add an unattended plaintext key fallback to satisfy headless readiness. A target without the desktop app can establish CLI-only support, not prove absence from an installed app; qualify evidence accordingly.

Acceptance criteria

  • A real authorized Linux target installs, upgrades, rolls back and diagnoses without mixed versions or plaintext prompt artifacts.
  • Hidden execution and any claimed visible route have client-real evidence; headless/unsupported visible states are explicit.
  • Wrong user/session, locked key store, restart, disconnect and duplicate-controller/alias cases reconcile the same request without blind replay.
  • Windows and Linux targets appear together in the existing controller UI with distinct capability and error states.

Validation and evidence level

Native Linux packaging and account/session tests, connector and Go integration gates, encrypted artifact scans, and harmless real-target runs tied to exact versions. Test the declared distributions and session types; do not infer all Linux environments from one host.

Dependencies and risks

Depends on #147 and the core acceptance #150. Reuse #142 protocol, #143 inventory/trust, #144 credentials and #145 audit without changing their guarantees; new protocol needs version negotiation and scoped compatibility work.

Out of scope

Automatic enablement of SSH on an unreachable host, a general remote shell, or claims that a headless Linux machine has an app-visible conversation.

Delivery boundary

One implementable branch/PR closes this issue only. Parent #141 remains the core delivery tracker; this extension has its own evidence and does not retroactively change #150. No real prompts, credentials or unredacted host logs in GitHub.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions