SSH keys & audit

The SSH keys tab of a server’s Users & SFTP section (/servers/:id/users) gives you one box-wide view of every authorized key on the VPS — which user it opens, whether MZPanel added it, and whether anything looks off. authorized_keys tells you what’s active but not who added it or when, so MZPanel keeps a small provenance sidecar on the box and cross-references it with the live keys. It’s available on all plans (Free).

Add or generate a key, step by step

1. Open the SSH keys tab and click Add key to reveal the quick-add bar.
2. Pick the target user (root and every login/SFTP user on the box are listed).
3. Paste a public key — or click Generate SSH key to mint a fresh ed25519 pair right in your browser. The public key drops into the box and the private key is revealed once for you to Copy or Download; it never leaves the page.
4. Optionally tick Grant sudo and/or SSH allow-list to add that user to the sudoers and the sshd AllowUsers set in the same step.
5. Click Authorise key. The new row appears in the audit as a Panel-sourced key, recorded with who added it and when.

Tip

No key yet? Generate SSH key is the safe path — the private half is created and shown client-side, MZPanel only ever handles the public key. If you’d rather install it from a terminal you’re already logged into, Copy command hands you a one-liner that appends the key to ~/.ssh/authorized_keys.

What else you can do

The tab is a searchable list of key cards — user, type and bits, fingerprint, comment/label, source, and date — with anomalies surfaced as chips.

• Filter and search — narrow to Foreign, Root, or Weak keys (each filter only shows when there’s something to see), and search across user, fingerprint, and label.
• Revoke a key — remove it by fingerprint (with a confirm step); the entry is also pruned from the provenance registry.
• Mark known — acknowledge a reviewed foreign key. It keeps a muted “known” chip and drops out of the anomaly count, so the audit reflects only what you haven’t reviewed yet.
• Label a key — store a friendly name against a fingerprint without ever rewriting authorized_keys (works for foreign keys too).
• Export — download the full audit (not just the filtered view) as CSV. No key material is ever included, so it’s safe to share.

Anomaly chips

The audit flags keys that deserve a second look:

Chip	What it means
Foreign	In authorized_keys but not added through MZPanel — installed by hand, cloud-init, a script, or pre-existing. A signal, not proof.
Root	Authorized on the root account.
Weak	DSA, or RSA under 3072 bits.
Duplicate	The same fingerprint opens two or more accounts.
No comment	No identifying comment on the key.

How it works

The list reads the agent-pushed ssh_keys inventory — the agent’s native collectSSHKeys scans every user’s authorized_keys, cross-references the sidecar provenance registry at /etc/mz/ssh/provenance.json, and returns metadata only (user, type, bits, fingerprint, comment, source, date). Key bodies are never read or shown. The snapshot is cached on the control plane, so the page loads instantly, and re-pushes after every change.

Actions dispatch user.key-* jobs to the agent, which runs them natively:

Action	Job	Agent does
Add key	user.key-add	appends to the user’s authorized_keys, records source: panel
Revoke	user.key-remove	removes by fingerprint, prunes provenance
Mark known / undo	user.key-ack / user.key-unack	flips acknowledged in the registry
Label	user.key-label	stores a friendly name in the registry

Because the label and mark-known state live only in the provenance sidecar, they never touch authorized_keys — labelling or acknowledging a key changes nothing on disk about the key itself.

CLI & automation

Every action maps to an mz command on the box — the same engine the dashboard drives. SSH in and run them directly, or let an on-box AI (ClaudeCode) run them:

mz user key-audit --json                          # the box-wide audit this page shows
mz user key-add <user> "ssh-ed25519 AAAA…" --json # authorise a public key
mz user key-remove <user> <fingerprint> --json    # revoke by fingerprint
mz user key-label <fingerprint> "CI deploy" --json # store a friendly label

key-ack <user> <fingerprint> / key-unack <fingerprint> toggle the “known” flag. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• Provenance is a signal, not proof. “Foreign” means only “not added through MZPanel.” A hand-added key that happens to reuse a fingerprint MZPanel once managed will still read as Panel.
• MZPanel never auto-deletes foreign keys. Removing a key is destructive and it might be a legitimate key of your own — you always make that call. Reviewed one you trust? Mark known to silence its chip.
• Needs the agent online. The audit reads through a live agent; when the server is offline the tab shows “Agent offline” rather than stale rows.
• The private key is shown once. After Generate SSH key, copy or download the private half immediately — MZPanel keeps nothing, and dismissing the panel loses it.
• Per-user key management also lives in the Users tab. This tab is the cross-user audit lens; the same add/remove for a single user is available inside that user’s drawer under Users.

Related

• The mz CLI — driving the box from the command line.
• Command catalog — every mz subcommand.