Users & SFTP

The Users & SFTP section of a server (/servers/:id/users) manages the Linux accounts on that box — who can SSH or SFTP in, who has sudo, and which SSH keys are authorised. MZPanel is key-only by design (password login is disabled), so per-user SSH-key management is the centrepiece. Available on all plans.

The page has two tabs: Users (the per-user list) and SSH keys (a box-wide audit of every authorised key across all users).

Add a user, step by step

1. Click Add user to open the create drawer.
2. Enter a Username — lowercase letters, digits, _ and -, starting with a letter or _ (the same rule the box enforces).
3. Pick an Access level:
   • Full shell — SSH access with a login shell (/bin/bash).
   • SFTP only — file transfer only, jailed to the home directory (/usr/sbin/nologin).
   • No login — a service account with no interactive access.
4. Optionally toggle Grant sudo, Allow SSH/SFTP login (AllowUsers) to add the user to the SSH allow-list, paste an SSH public key, and Bind to site to add the user to a site’s group and make its web root group-writable (SFTP deploy access to that one site).
5. Click Create user. The card appears in the list; if you pasted a key it’s authorised in the same step.

Caution

Allow SSH/SFTP login (AllowUsers) changes SSH server policy: if no allow-list exists yet, enabling it restricts SSH & SFTP to root plus the allowed users. Make sure your own account is covered before you rely on it.

What else you can do

Each user renders as a card showing username, kind (Site / Login), home path, access level, sudo/sftp/locked chips, last login, and its authorised-key count.

• Filter and search — by All / Site / Login / SFTP / Sudo, and search by username.
• Access & SSH keys — open the per-user drawer to see connection details (host, port 22, ready-to-copy sftp/ssh commands) and manage that user’s authorised keys: paste a public key, or Generate an ed25519 pair in your browser (the private key never leaves the page — download it before you close).
• Grant / revoke sudo and Lock / unlock a user (root is protected — always has sudo and can’t be locked).
• Delete a user (and its home directory). If the user owns a site, MZPanel warns you to delete the site instead so its files aren’t orphaned.
• SSH keys tab — audit every authorised key on the box: filter Foreign (keys MZPanel didn’t add), On root, or Weak (DSA, or RSA under 3072 bits); give a key a friendly label; mark a foreign key known so it stops counting as an anomaly; and Export the full inventory as CSV.

How it works

Actions on this page dispatch user.* jobs (and read the users / ssh_keys inventory) to the server’s agent, which runs them natively:

Action	Job	Agent runs
List users	users inventory	users list (agent-pushed cache)
Create	user.add	useradd --create-home + shell/group/site wiring
Delete	user.delete	userdel (optionally keep home)
Grant/revoke sudo	user.sudo	usermod -aG sudo / gpasswd -d
Lock/unlock	user.lock	chage -E 1 / chage -E -1
List a user’s keys	user.key-list	reads ~/.ssh/authorized_keys{,2}
Add/remove key	user.key-add / user.key-remove	rewrites authorized_keys
Key audit	ssh_keys inventory	scans every user’s authorised keys
Label / acknowledge key	user.key-label / user.key-ack / user.key-unack	updates the provenance registry

The user list and key audit come from the agent-pushed inventory cache, so the page loads instantly and still shows the last-known state when the server is offline. The list is re-pushed after every add/delete. Locking uses account-expiry (chage -E), which blocks SSH-key auth as well as password login. The agent never sends key material up — it reports only how many keys a user has — so the per-user drawer reads the real fingerprints live via user.key-list.

CLI & automation

Every action here 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 users list --json                                  # every account on the box
mz user add deploy --shell /bin/bash --sudo --json    # create a sudo shell user
mz user key-add deploy "ssh-ed25519 AAAA… you@host" --json
mz user sudo deploy off --json                        # revoke sudo
mz user lock deploy --json                            # disable login (chage -E 1)

Note the list command is mz users list (plural); the per-user actions are mz user <action>. Always pass --json for machine output. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• root is protected. You can’t lock root or revoke its sudo, and those controls are disabled on the card — that’s deliberate, so you never lock yourself out.
• Deleting a site user orphans its files. A user marked Site owns a WordPress site’s files; delete the site (which cleans up its user) rather than the user directly, or its web root is left without an owner.
• Password login is disabled — no key means no access. A user with no authorised SSH key can’t connect at all. Add or generate a key in the per-user drawer before handing out the account.
• Generated private keys are shown once. When you Generate a key in the browser, download the private key before closing the panel — it’s never stored and can’t be recovered afterward.
• Foreign / weak keys are flagged, not blocked. The SSH keys audit surfaces keys MZPanel didn’t add and cryptographically weak keys so you can review them; it doesn’t remove them for you. Acknowledge the ones you trust, remove the rest.
• Offline servers show a cached preview. The list and audit render from the last-known cache; creating, locking, and live key reads need the agent online.

Related

• Cron jobs — the Run as user picker reads these accounts.
• Services — daemons and background processes on the box.
• The mz CLI — driving the box from the command line.