CLI Reference

Mezite provides four command-line tools for interacting with your SSH access platform. Each binary serves a distinct role in the Mezite ecosystem.

Binaries

Binary	Description
`msh`	Client CLI for end users. Authenticate, open SSH sessions, transfer files with SCP, list available nodes, and manage access requests.
`mezctl`	Admin CLI for cluster operators. Manage users, roles, join tokens, audit logs, access requests, and auth connectors.
`mezd`	Node agent installed on every SSH host. Connects to the Mezite proxy via a reverse tunnel, handles certificate-based authentication, and records sessions.
`mezd identity`	Agent identity subcommand for CI/CD pipelines and automated services. Continuously renews short-lived certificates so non-human workloads can authenticate to Mezite. Run as `mezd identity start`, or set `MEZITE_IDENTITY_DIR` and `MEZITE_IDENTITY_TOKEN` in the environment of `mezd start` for combined mode (`mezd start` registers no flags — identity is configured via environment variables only).

mezhub and mezd

mezhub is a server binary and mezd is an agent / workload-identity binary; neither is a general-purpose CLI you run interactively. Their relevant subcommands and flags are documented in the surfaces that operate them rather than on their own reference page:

mezhub — Run as a systemd service or a container. Its only flag is --config <path>; the full configuration (every YAML field and environment variable) is documented on the Configuration page. Deployment recipes are under Deployment. It also exposes mezhub healthcheck, which exits non-zero if the local server is not healthy — handy as a container health probe where an HTTP check is awkward.
mezd start — Run as a systemd service on every node. mezd start takes no flags; all configuration is environment-variable driven. See the Agent Configuration section of the Configuration page.
mezd identity — Long-running workload-identity daemon. Exposes a Unix socket that local workloads connect to in order to fetch SPIFFE X.509-SVIDs and JWT-SVIDs, and renews them on a timer. Configured via the MEZITE_IDENTITY_* and MEZITE_WORKLOAD_SOCKET environment variables, or the equivalent flags on mezd identity start — see the Workload Identity section of the Configuration page.
mezd identity get aws-creds — Exchange a JWT SVID from the local workload socket for temporary AWS credentials via sts:AssumeRoleWithWebIdentity. Emits shell exports (--format env, the default), JSON suitable for an AWS credential_process, or a credentials-file block. Requires mezd identity start to be running and an OIDC provider plus IAM role configured in the target account — mezctl integrations configure aws-oidc prints what to apply.

Getting Started

Most users will start with msh to log in and open SSH sessions. Cluster administrators should also install mezctl for user and role management.