============================================================
Status: INVENTORY v0.3, 2026-10-17 — report-only. No credential has been removed or rotated by this page. It
exists because the two errors of 2026-10-15 (WO-M4's "no access", and the pooler's "carries / does not carry the
literal") were both about which machine and which value — so the artefact that prevents them is a single table of
what we hold → which host holds it → what consumes it → whether it is needed in tunnel-only mode → keep/remove.
2026-10-17 (session 88) — correction, measured. Writing the technical specification put this register to the test it exists for. Both client-vps instances in the development estate accept our estate key as root today (the GP one because the key was re-installed at the 2026-10-15 build visit), SSH is reachable on both, and the GP client-vps binds PostgreSQL to all interfaces — public access is dropped by its firewall, verified by an external probe, so no records are exposed, but the posture is dev mode on both client-vps instances. That is now the ruling, not a lapse (Matthew, 2026-10-17): the client-side applications are still being developed on these client-vps instances, so the login stays until example-model client-vps instances exist. The estate is therefore three roles — dev/canary (ours, key present), example model (the extra test boxes to be provisioned: installed, key then removed, tunnel-only), production client (no login from handover). What this changes is what we may claim today: the no-login posture is warranted for a reference or production box, and no box in the estate holds it yet. See the technical specification §3.2.
v0.3 folds in the estate ruling (Matthew, 2026-10-15; A5). The two test-estate Client VPSes are a permanent
test estate, dev mode is their standing operating mode (not a rehearsal phase), and the dental/estate SSH key
is kept, not a cleanup candidate. The access-mode column below is therefore a standing state, not a snapshot;
the two boxes are the estate's exemplars of dev mode and tunnel-only posture. The production promise ("we hold no
standing login") applies to a real client's box.
Scope: the test estate — two Client VPSes, three tenants. Production clients are provisioned per the
SIAAS model and are not in this table.
| Client VPS | Public IP | Tenant(s) | Access mode (standing state) |
|---|---|---|---|
| GP Client VPS | 77.68.97.101 |
test-client | dev mode in practice, though recorded as the tunnel-only exemplar. MEASURED 2026-10-17: the estate key (/root/.ssh/vps_client) logs in as root — it was re-installed at the 2026-10-15 build visit (see §A), so the "revoked 2026-08-11" reading above was stale; port 22 is reachable from the internet, password auth refused, and PostgreSQL binds all interfaces (public access dropped by the firewall). The break-glass root password is held 0600 at /root/.secrets/test-client-root.pass, console-only. Neither client-vps is currently in tunnel-only posture. |
| Dental Client VPS | 194.164.18.33 |
test-client-dental, test-client-pharmacy | SSH / dev exemplar — /root/.ssh/vps_client is authorised here by design, and the ruling keeps it (not a cleanup candidate). |
| Item | What it is | Consumer | Tunnel-only need | Recommend |
|---|---|---|---|---|
/root/.ssh/vps_client (private) |
root SSH key — the estate key; its public half is authorised for root on both test-estate Client VPSes (the GP one installed 2026-10-15 at the build visit) |
our direct access | not used | keep — dev mode is the estate's standing mode; NOT a cleanup candidate (the dental box's authorised key is the intended state; only a box switched to tunnel-only would drop it) |
/root/.secrets/test-client-root.pass (0600) |
the GP Client VPS's break-glass root password — issued for the 2026-10-15 build visit and rotated at its close (the value had travelled through a chat transcript) | fallback access only | not used | keep 0600; console break-glass only — SSH no longer accepts passwords on this box (key-only since 2026-10-15); the standing path is the estate key |
/root/clientadmin-key (private) |
SSH key to the GP VPS as clientadmin |
none — refused, not revoked (no accepted entry in the box's authorized_keys; corrected 2026-10-15) |
not used | remove (dead) |
/root/client-credentials.json (GP) |
DB app_user/app_password, client_admin_user/_password, pgadmin email/password, tunnel, vps, backups |
check-tunnel-health.py --tenant-slug test-client (reads only database.name/app_user/app_password) |
yes (the probe) | keep database.app_user; remove client_admin_* + pgadmin |
/root/client-credentials-dental.json |
DB app_user/app_password + client_admin_user/_password, vps, tunnel, backups |
tunnel-health (test-client-dental) |
yes | keep app_user; remove client_admin_* |
/root/client-credentials-pharmacy.json |
DB app_user/app_password, tunnel |
tunnel-health (test-client-pharmacy) |
yes | keep |
/root/client-credentials-dev-client.json |
same shape, incl. client_admin_* |
none (cron commented; dev-client mothballed) | no | remove |
/root/client-handover.md |
GP handover, incl. plaintext DB/admin/backup passwords + a copy of the old SSH key | a client would hold this; we should not retain the secrets | no | remove / relocate the secrets |
/root/cloud-init-test-client{,‑dental}.yml |
provisioning records with an embedded Postgres password and WireGuard private keys | provisioning reference | no | remove / redact |
/root/.dental-test-client-db-pw |
a dental DB password, plaintext (21 B) | unknown | no | investigate, then remove |
/root/.ssh/client_vps_tunnel (private) |
our copy of the dental VPS's reverse-tunnel key | the VPS's own tunnel (a copy should live only there) | the tunnel is the transport | review — shouldn't need a copy here |
dsp_clinic)| Item | What it is | Consumer | Tunnel-only need | Recommend |
|---|---|---|---|---|
infrastructure_clientvps.client_db_password (dental set) |
the client's master DB password — also rendered in the admin UI (clientvps_detail.html) |
provisioning only | no | remove (SIAAS: the client owns root/admin) |
infrastructure_clientvps.app_db_password |
provisioning record of the app-user password | provisioning only | — | review (keep only if something tracks it) |
infrastructure_clientvps.maintenance_token / job_secret (encrypted) |
the box agent identity + signing secret | the poll + signed jobs | yes | keep |
tenancy_tenant.db_password (encrypted) |
the app's DB credential per tenant | the app, tunnel-health | yes | keep |
tenancy_tenant.minio_access_key / minio_secret_key (encrypted) |
the tenant's object-store credential | the app (dental) | yes | keep |
tenancy_tenant.orthanc_url / orthanc_username / orthanc_password |
Orthanc access | dental app | yes | keep |
tenancy_tenant.webhook_token / backup_heartbeat_token |
ingest tokens | app / cron | yes | keep |
| Item | What it is | Consumer | Keep? |
|---|---|---|---|
/etc/veripath/pgbouncer/{pgbouncer.ini,userlist.txt} (0600) |
per-tenant server creds + the pooler user | the dev pooler | keep; regenerate at the rotation window |
/etc/veripath/clients.json (0600) |
capacity-monitoring creds | capacity cron | keep |
/etc/veripath/maintenance.env (0600) |
client maintenance token | reporter | keep |
| Item | What it is | Notes |
|---|---|---|
dental: /root/.ssh/client_vps_tunnel + primary-tunnel.service / pharmacy-tunnel.service |
the outbound reverse-tunnel key | the VPS's own; the tunnels are outbound, so tunnel-only does not need our login |
dental: MinIO/SeaweedFS s3.json (0600) + the MinIO container env |
the object-store credentials | now serving dental-radiographs (WO-M4); the app authenticates with minioadmin + that secret |
Only the restricted functional secrets: each tenant's DB app_user (in the tenant row and the monitoring files),
its object-store key, its Orthanc creds, and the ingest/agent tokens. Nothing else — no root/admin DB password, no
pgAdmin, no handover secret, no clientadmin-key. That is the SIAAS line: the app reaches the VPS through the
tunnel with a restricted user; we hold no login to the machine.
The cleanup is deferred (Matthew, 2026-10-15) — this page is the map for it. When it runs: strip
client_admin_*/pgadmin from the client-credentials*.json files (verify tunnel-health still greens), remove
client_db_password from the registry and its UI, and purge clientadmin-key, client-handover.md,
cloud-init-*.yml, .dental-test-client-db-pw — each after confirming no live consumer.
Out of scope for cleanup: the estate key (/root/.ssh/vps_client) and its authorised entry on the dental
box. Under the estate ruling dev mode is the test estate's standing mode, so the key is kept; only a box that is
deliberately switched to tunnel-only would retire it (see the access-mode switch).