[FEATURE]: 1Password (and general password-manager) integration for SSH credentials

Title

1Password (and general password-manager) integration for SSH credentials

Platform

Web-app

Is it related to an issue?

Many of us keep every SSH key and server password in 1Password as the single source of truth. Today Termix requires copying those secrets into its own encrypted SQLite store, which means: secrets are duplicated and drift out of sync when rotated in 1Password; the vault's benefits (rotation, auditing, sharing policies, hardware-backed unlock) don't extend to Termix; and there's no way to use 1Password's SSH agent, which is its primary SSH feature.

Because Termix makes SSH connections server-side rather than from a local client, the standard "1Password SSH agent -> local OpenSSH" flow doesn't apply, so native support inside Termix is really the only path.

Related existing issues (different scope — please don't close as a duplicate):

• #338 — password-manager autofill + biometrics, but scoped to the iOS app login only, and doesn't mention 1Password.
• #269 — HashiCorp Vault (closed); this asks instead for a consumer-grade password-manager path.
• #84 — Bitwarden SSH agent question (closed).
• #179 / #90 / #654 — SSH agent / forwarding groundwork this could build on.
• #821 — YubiKey PKCS#11 (closed); similar "external key source" theme.

The Solution

Add first-class support for sourcing SSH credentials from 1Password instead of storing them only in Termix's database. Ideally designed generically as an "external secret source" so Bitwarden/Vaultwarden and others can plug into the same mechanism, with 1Password as the first target.

Approaches (any one would help; roughly easiest -> deepest):

1. Secret references at connect time — let a host's password/key field hold a 1Password secret reference (op://vault/item/field) resolved via 1Password Connect or the op CLI on the Termix backend, so Termix fetches the secret on connection instead of storing it. Fits the self-hosted model well.

2. 1Password SSH agent forwarding — let the Termix backend talk to a 1Password SSH agent (a forwarded local agent, or a Connect-based agent) so key material never leaves the vault. Builds on the agent-forwarding work in #654 / #179 / #90.

3. Web/desktop autofill compatibility — structure the web UI credential fields so the 1Password browser extension can autofill them cleanly (complements the iOS-focused #338).

Additional Context

1Password exposes several integration surfaces this could target — the SSH agent, the op CLI, secret references, and 1Password Connect (self-hostable) — so a Termix implementation wouldn't need to depend on 1Password's cloud.

The issue names no files, tests, or entry points. Start by reviewing the SSH agent groundwork in issues #179, #90, and #654, then choose and scope one integration approach; done should define how credentials are sourced from 1Password without requiring duplicate storage in Termix.