Credentials Reference¶

Credential Locations¶

Infrastructure Access¶

Application Credentials¶

VPN and Tunnel¶

Third-Party Accounts¶

Retrieving Credentials¶

AstraPBX API Token¶

ssh root@89.116.31.109
grep API_KEY /opt/astrapbx/.env

Zoiper User Password¶

Query the database on the cloud server:

ssh root@89.116.31.109
psql -U astrapbx -d astrapbx_db -c "SELECT username, password FROM extensions WHERE username = 'org_mna9x47k_1001';"

WireGuard Keys¶

# On either server
sudo cat /etc/wireguard/wg0.conf

Security Policies¶

Never do these:

• Never commit passwords, tokens, or private keys to git
• Never share credentials over Slack, email, or any unencrypted channel
• Never store credentials in plain text files outside of the designated locations above
• Never reuse passwords across services

Always do these:

• Share credentials only through secure, ephemeral channels (in person, encrypted messaging, or a secrets manager)
• Rotate shared credentials when a freelancer or contractor's access is revoked
• Use SSH keys instead of passwords for server access
• Use unique, generated passwords for each Zoiper user account

Access Revocation Checklist¶

When a freelancer or contractor finishes their engagement:

• [ ] Remove their SSH user account from the cloud server
• [ ] Remove their SSH user account from the NUC (if applicable)
• [ ] Remove their SSH public key from all authorized_keys files
• [ ] Remove their email from Cloudflare Access policies
• [ ] Disable or delete their Zoiper extension credentials
• [ ] Rotate the AstraPBX API token if they had access to it
• [ ] Rotate any other shared secrets they may have seen
• [ ] Revoke GitHub access if they were added to the astradial org
• [ ] Review and remove any WireGuard peer configurations they used

Rotation History¶

A running log of credential rotations. Why this exists: when a rotation happens because of a leak, future-you needs to know what was in scope (so you can stop trusting any artefact dated before the rotation).

Entries are most-recent-first. Don't put actual rotated values here — only state what was rotated and where the new value lives now.

2026-05-17 — leaked-secret sweep¶

Audit driven by gitleaks scan of internal-docs + astradial-platform. Found several real credentials committed to repos. Rotated all that were live on prod or staging; documented value still hot but pending for the one we can't rotate without customer access (V7 SIP trunk).

Note on V7 trunk registration state at time of rotation: The trunk was already Unavailable (UCM not actively registering) for ~20 hours before the rotation — matches the existing "trunk-to-trunk gating" issue tracked in v7-setup.md. The rotation succeeded at the security layer (leaked password no longer accepted by cloud), but verifying end-to-end registration with the new password requires the trunk to recover from the pre-existing operational issue, which is separate work (Grandstream + BSNL meeting).

Residual scrub TODO: /etc/asterisk/pjsip_vseven_hotels.conf on prod has a doc-comment line ; Password: eb5b4c952... that's still plaintext on disk. Not security-active (Asterisk ignores comments) but should be auto-cleaned on next API-driven config regen for V7.

Audit-trail also affected (rotated as side-effects)¶

• Audited pbx_api_user@localhost (second MariaDB user) — not vulnerable to the leaked weak password (different hash). Left alone.
• Audited pipecat_org_config.google_api_key for all orgs — never leaked to any repo. Left alone (still cleartext in DB; future hardening item).
• Audited org_api_keys table — empty, no rotation needed.
• Removed api/config/config.js fallback to pbx_secure_password — the code now requires DB_PASSWORD env var (no insecure default).
• Untracked internal-docs/.claude/settings.local.json (added to .gitignore) — the file held cached curl commands with the leaked GE API key in Bash permissions strings.

Hardening follow-ups (future work, not rotations)¶

These came up during the audit and are worth tracking:

• res_odbc.conf should be env-templated, not have literal passwords committed. Convert deploy pipeline to substitute ${ODBC_PASSWORD} from /opt/astrapbx/.env at deploy time. Same for cloud-prod and cloud-staging variants.
• Cleartext secrets in prod DB (data at rest): users.sip_password, sip_trunks.password, customer_tunnels.preshared_key, organizations.api_secret, webhooks.secret, pipecat_org_config.google_api_key. Anyone with DB access can read them all. Eventual fix: encrypt-at-rest with a KMS-managed key, or at minimum tighten DB-user grants.
• api/docs/deployment/SESSION_LOG.md + VPS_DEPLOYMENT.md — contain full prod SSH playbook + DB-delete commands. They're scrubbed of pbx_secure_password now but still expose prod VPS IP, hostnames, and operational layout. Consider moving content to this repo (docs/operations/) and deleting from astradial-platform.
• pbx_user/pbx_api share their password with the API .env. If the API leaks its env, the ODBC password leaks too. Eventually want separate users with separate passwords for Asterisk-side ODBC vs. Node API connection.

Discipline going forward¶

• Never commit a real password to either repo, even on staging. Treat .env-style values as "lives only on the VPS." Use templates like __ODBC_PASSWORD__ placeholders in committed config files and let the deploy pipeline substitute them.
• For local-only mariadb rotations, always use mariadb -uroot (socket auth on the Linux root), feed SQL via stdin from a mktemp file with mode 600, redirect stderr to /dev/null. The -e "ALTER USER ..." form echoes the SQL on errors, which can expose the new password value back to stdout — that's how this audit's first attempt leaked the new staging password into a chat transcript.
• When a credential is committed, rotating is the only thing that makes the value worthless. Git history rewriting / force-push is cosmetic — it doesn't reach existing clones, cached commit URLs, or anyone who already read the page. Rotation is the load-bearing step; scrubbing is hygiene.