Skip to main content

Every role has an SSH key in its home

Roles manage machines: the homelab host, a NAS, devices on the home network. A plan from when roles were custom agents was to keep keys in Mission Control and lend them to a run through an SSH agent, so the key stayed opaque to the agent. Since ADR 0023 a role is closer to a person at a computer of its own: it has a home it keeps, it works with git and the forge's CLI itself, and its container is its own machine. We decided that every role has an SSH key in its home, as a person has one on their own machine: Mission Control makes an Ed25519 key pair at ~/.ssh/id_ed25519 the first time the home is set up, never replaces it, and shows its public half where the role is (Copy public key in the role's menu, GET /roles/:roleId/ssh-key, mission-control role ssh-key), so people add it to the machines the role may reach. Agents use ssh, scp, rsync and port forwarding themselves, which the agent image ships.

Considered Options​

  • An SSH agent serving keys kept in Mission Control: rejected for a role's own key. The agent holds the socket, and so can use every key it serves as it likes; hiding the private key buys little against that, while forwarding a socket into every container and pod is a component of its own to build and keep. It may still suit keys shared between roles; see below.
  • Keys in Mission Control, written into the home before every run, like triggered skills (ADR 0026): deferred to shared keys. For a role's own key the home already is the place it is kept, for as long as the role; a copy in the database adds a second place to keep in step.
  • An SSH tool in Mission Control: rejected. SSH is used for too many things (a shell, a copy, a tunnel, a pipe) to put behind a tool, and a tool is the shape ADR 0023 moved away from.
  • The agent making its own key: rejected. A person needs the public key before the role's first run to give it access, and a key that depends on the agent remembering to make it is one it will sometimes lack.

Consequences​

  • The private key is the role's. It lives in the home with the role's other files, on the server's data volume, readable by the server's user, and goes when the role and its home go. Who can read the data directory can read it, as with everything else in a home.
  • Rotating a key is a person's act: delete it from the home and the next run or request for the public key makes a new one; nothing rotates it on a schedule.
  • New hosts are trusted on first sight. No one is there to answer ssh's question about an unknown host, so the agent image sets StrictHostKeyChecking accept-new: a new host's key is remembered in the role's known_hosts, and a changed one is refused.
  • Reaching a machine is a separate grant. A key opens nothing a role cannot reach; where agents run as pods, which networks they reach is the server's configuration.
  • Keys shared between roles come later, as a manager in Mission Control for keys that are kept sealed and assigned to roles, which may well write them into the home in the way of ADR 0026.