SSH (Connection Manager)

The SSH view is a top-level manager for saving and launching SSH connections to remote servers — even servers that do not run the Hive daemon (hived). Most machines you want to reach over SSH will never have Hive installed; this view lets a Hive node act as the jump-off point, opening a normal Hive terminal session that runs ssh user@host for you.

Open it from the SSH entry in the left nav (route /ssh).

Saved connections

A saved connection stores everything needed to open a session:

• Display name — a label shown on the connection card.
• Host / IP and Port (default 22).
• Username.
• Remote directory (optional) — a directory to cd into on login.
• Authentication method (see below).
• Extra ssh arguments (optional) — raw flags appended to the ssh command line, e.g. -o StrictHostKeyChecking=accept-new.

Each connection card has Connect, Edit, and Delete actions. Deleting removes only the saved connection — it never touches anything on the remote server.

Authentication methods

• SSH agent / default keys — no secret is stored. Relies on a running ssh-agent or the node's default ~/.ssh keys.
• Private key file — an absolute path to a private key on the node that runs ssh (not on the client), plus an optional passphrase. The key itself is never copied into Hive; it is referenced by path only.
• Private key (stored in cluster) — paste or load a private key; the key material is encrypted and stored on the node, then written to a temporary 0600 file only at connect time.
• Password — a stored password. The daemon feeds it to ssh via an askpass helper. Key-based auth is more reliable; treat the password method as a convenience.
• Saved key (from vault) / Saved password (from vault) — reference a reusable credential from the node's credential vault instead of retyping a secret per connection (see below).

Credential vault

The Manage credentials button next to New connection opens a reusable credential vault: named keys and passwords stored once, encrypted on a node, and shared across that node's saved connections.

• Add a credential with a name, a type (private key or password), the secret material, and — for keys — an optional passphrase. Keys can be pasted or loaded from a file on the node.
• In a connection's Authentication section, pick Saved key or Saved password and choose the credential. Editing the credential updates every connection that references it.
• A credential cannot be deleted while a connection still uses it — reassign or delete those connections first.
• Like connections, credentials are node-local: the vault belongs to the node selected in the manager (and in the connection's storage-node picker).

Node selection

Connections are node-scoped. The node picker at the top of the view (the same NodeSelector used by the Files view) chooses which node's database stores the connection — and which node originates the ssh process when you connect. In a cluster, this is how you pick which node reaches out to the remote server.

Connecting

Clicking Connect launches a normal Hive terminal session running ssh user@host. Because the session is spawned by the daemon (not by the client), it behaves exactly like any other Hive terminal session:

• It persists when you close or reload the app. Reconnect later and the SSH session is still alive.
• The app navigates you straight to that terminal.

Security and credentials

• Passwords and key passphrases are encrypted at rest in the daemon's SQLite database using XChaCha20-Poly1305, under a per-node master key auto-generated in the daemon config (ssh_secret_key).
• Private keys are referenced by path only — never copied into Hive.
• Secrets are never sent back to clients. Listing connections reveals only whether a secret is set, not the secret itself. The daemon decrypts a secret only at the moment it launches the ssh session.
• When editing a connection, leaving the password / passphrase field blank keeps the previously stored secret; typing a new value replaces it.

Limits

This is a v1 feature. Worth knowing:

• Password / passphrase auth is Unix-only and needs OpenSSH 8.4+ on the node (the daemon uses an askpass helper with SSH_ASKPASS_REQUIRE=force). On older ssh, it falls back to prompting in the terminal — you can simply type the secret there.
• No SFTP / file transfer, no ProxyJump / jump hosts, and no port forwarding.
• Connections and saved credentials are not cluster-replicated — they live only on their owning node.
• known_hosts / StrictHostKeyChecking behaviour follows the node's ssh defaults unless you override it via the extra ssh arguments field.