Skip to content

Host credentials for Termix

Termix keeps an SSH host's password or key in SecretHive, not in its own database. Its Secret Sources plugin fetches the secret each time a session connects, from a reference such as op://termix-hosts/web-1/password. The plugin speaks only the 1Password Connect API, so SecretHive answers the read side of that API.

Status 2026-10-21: from server 0.28. Tested with the plugin's own client code (Termix-SSH/Plugin-Secret-Sources, commit 91f9d41b34) against a real server.

What SecretHive answers

Three calls, all reads, under /api/1password-connect:
GET /v1/vaults The vaults the key's owner has a role in. ?filter=title eq "name" narrows to one
GET /v1/vaults/{vault}/items The secrets in a vault, without values. ?filter=title eq "name" narrows to one
GET /v1/vaults/{vault}/items/{secret} One secret with its fields, values included

A vault is a vault and an item is a secret; the names are the ids. Names match without regard to case. An item's fields:

Field What it is
password The secret's value
private_key (label private key) The value again, when the value is a private key (it starts with a -----BEGIN ... PRIVATE KEY----- line)
Every sensitive field By its name, concealed
Every ordinary field By its name: username as the user name, url as an address

Certificates are not offered. Nothing can be changed through these routes, and any other filter than title eq is refused, not ignored.

What is on record

The item call hands over every value of the secret, because the plugin picks its field only afterwards. Each value is a read on record, by the key's owner, as through the rest of the API. A secret with a value and one sensitive field is two rows every time Termix connects with it, also when the reference asks for the user name. Termix keeps an answer for a minute.

Keep a vault for Termix with only what it needs: the password or the key of each host, and its user name as an ordinary field.

Setting it up

  1. Make a vault, for instance termix-hosts, and put each host's credential in it as a secret: the password or the private key as the value (a key spans lines, which only a value may), the user name as the field username.
  2. Make a service identity termix with Secrets User on that vault, and a key for it limited to that vault and that role, and to the address Termix connects from.
  3. In Termix, under a host's Secret sources, add a source: the URL https://secrethive.example.org/api/1password-connect and the key as the access token. Test says how many vaults it sees: one.
  4. In the host's password or key field, write a reference instead of the secret:
op://termix-hosts/web-1/password
op://termix-hosts/web-1/username
op://termix-hosts/deploy-key/private key

A host's password is then changed in SecretHive only. Termix stores the reference and the key, never the secret.

When it is refused

Answer Why
401 No key, or one the server does not know
403 The key may see the vault but not read values (a Reader, or a key limited to Reader)
404 No such vault for this key, or no such secret
400 A filter other than title eq "...", or the secret is disabled

The plugin reports these as "vault not found", "item not found" or "HTTP 403"; no message holds a value.