Accounts and logins at welland

You look after access to the welland gateway and fleet: who can log in, how, and how to change it. Each task has its own page, listed under The tasks.

Who can log in to the welland gateway (tweed, inventory host fpgas.online) and to the netbooted Pi fleet, with what, and which role and variable decide it. Everything on these pages is what main configures. It was deployed to tweed (main 4de0b24) and checked live on 2026-09-29:

  • a password-only login to tweed gets Permission denied (publickey);

  • ansible (automation key), and admin and tim (GitHub keys), log in and get sudo -n to root, and carl holds exactly his GitHub key;

  • the jump account refuses commands, and its authorized_keys holds only Tim’s and Carl’s GitHub keys (the Launchpad lines are gone);

  • through -J pi@tweed, pi@ and root@ a board work with Tim’s key, and ansible@ a board works with the automation key, including sudo;

  • the jump account’s own key logs in to pi@ a board.

No secrets are recorded here. The only private material involved is the fpgas.online-ansible automation key (vaulted as vault_ansible_ssh_private_key in host_vars/fpgas.online.yml) and the vaulted pi_pw. The pi password is public by design: the board pages on fpgas.online publish it, and the boards are ephemeral and isolated per port.

At a glance

Where

Login methods

Who

tweed

SSH public key only (roles/sshd)

ansible (automation), admin (site services), tim and carl (operators), pi (restricted jump), root (key only)

Pi NFS root, every board pi-sw<S>-p<P> = 10.21.<S>.<P>

public key, plus a password for pi

pi (the web terminal and people), root, ansible (automation)

The Pis are not routable from outside tweed, so every login to a board goes through tweed.

The tasks

  • Logging in: the command for each account, from inside the site, over IPv6 or through the upstream router.

  • Verifying: which checks in verify-server.yml and verify-pi.yml cover access.