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 cluster-global - one shared vault visible and usable from every node.

Cluster-global vault

Connections and credentials are replicated across the whole cluster - there is no node picker. Every node holds the same set, so you manage one shared list no matter which node you are connected to. Saving, editing, or deleting on any node propagates to the others (last-writer-wins), and the view refreshes on every client automatically.

To make the encrypted secrets readable on every node, the cluster converges on a single shared ssh_secret_key: nodes elect the key belonging to the lowest-node-id member and re-encrypt their local vault under it. This is automatic and needs no operator action.

Clicking Connect originates the ssh process on the node you are currently connected to.

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 each node's SQLite database using XChaCha20-Poly1305, under a shared cluster master key (ssh_secret_key) the nodes elect and converge on so the vault decrypts on every node.
• 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.
• known_hosts / StrictHostKeyChecking behaviour follows the node's ssh defaults unless you override it via the extra ssh arguments field.