Security is not a feature — it is the foundation. Every design decision starts with the question: how does this protect the user's SSH infrastructure?
All user and host authentication uses short-lived SSH certificates signed by ECDSA P-256 CA keypairs. No static SSH keys are stored or distributed. Certificates are generated on demand and expire automatically.
Certificates default to a 12-hour TTL and the server caps any request at 24 hours. When a certificate expires, access stops. There are no long-lived credentials to rotate, leak, or forget about on departed employees' machines. A role's max_session_ttl is a separate control: it bounds how long a live session may run, and clamps certificates issued for cross-cluster access, but it does not shorten the validity of a certificate issued on the normal login path.
Mezite operates two CAs: a User CA and a Host CA. Users verify they are connecting to legitimate hosts, and hosts verify they are accepting connections from authorized users. Both directions are cryptographically verified.
Access control uses a deny-overrides-allow model. Deny rules always take precedence, ensuring that overly broad allow rules cannot accidentally grant access to sensitive resources. Roles are label-based and support template variables.
Beyond the core certificate-based authentication model, Mezite includes multiple hardening layers to reduce the blast radius of any potential compromise. Most are on by default; where a layer needs a deliberate choice from you, it says so below.
Every authentication attempt, certificate issuance, access decision, SSH session start/stop, and administrative action generates a structured audit event, written to the same database that holds cluster state. Writes are buffered and flushed asynchronously for throughput, with a synchronous path for security-critical events.
SSH sessions can be captured as structured recordings and played back for audit, compliance, or incident investigation. The agent captures terminal I/O on the target host, so the recording is not produced by — and cannot be turned off by — the person in the session. Recording mode is a cluster-wide setting agents pick up automatically, defaulting to streaming the recording to the auth service during the session so it survives a host failure rather than only being uploaded afterward; a per-agent override is available for a node that needs to diverge from the fleet.
Client-to-proxy, proxy-to-agent and agent-to-auth connections are all encrypted. The client, agent-gRPC and proxy TLS paths negotiate TLS 1.3; the reverse-tunnel and cross-cluster transports accept TLS 1.2 as a floor. The gRPC auth API presents a host-CA-issued server certificate; client certificates are accepted when presented but not required at the TLS layer, because a small number of join/register RPCs must be reachable before the caller has a certificate at all. Per-RPC authentication is enforced by the gRPC auth interceptor using a session bearer token or, for agent calls, an x-agent-id metadata header. On managed deployments where a TLS-terminating edge handles the public address, h2c is used between the edge and mezhub.
Every default listener is above 1024 (3023 SSH, 3024 tunnel, 3025 gRPC, 3080 HTTPS), so mezhub never needs a privileged bind and can run as a dedicated unprivileged service account. Note that the shipped systemd unit does not yet set User=, so a default systemd install runs mezhub as root until you add a service account — set one. On the managed service this is already enforced: the container image runs as UID 10001, and the Kubernetes pod sets runAsNonRoot, disables privilege escalation, and mounts a read-only root filesystem with writeable volumes only where state lives.
When MEZITE_CA_KEY_PASSPHRASE is set, the User and Host CA private keys are AES-256-GCM encrypted in the database (SQLite or PostgreSQL) with the master key derived via Argon2id. For higher assurance, CA signing keys can live in AWS KMS instead of the local DB — set the passphrase in production.
Mezite is a single statically-linked binary with zero external dependencies when using the built-in SQLite backend. No interpreted languages, no plugin systems, no dynamically loaded libraries.
The shipped mezhub unit sets NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes, and confines writes to /var/lib/mezite. The mezd agent unit deliberately does not: provisioning host users means writing /etc/passwd, /etc/shadow, /etc/group, /home and /etc/sudoers.d, so the agent runs with those protections off by design.
Every release publishes a SHA-256 checksums file signed with a keyless Sigstore (cosign) signature, plus an ed25519-signed manifest.json and the matching public key. Both can be verified before you run anything — cosign verify-blob for the checksums, and the manifest for the per-asset digests.
Enterprise customers receive a source-available license granting rights to read, audit, statically scan, and pentest the code under NDA — for security teams and regulated environments that require source-level assurance.
[Service]
Type=simple
ExecStart=/usr/local/bin/mezhub --config=/etc/mezite/mezite.yaml
Restart=always
RestartSec=5
LimitNOFILE=65535
NoNewPrivileges=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/mezite
PrivateTmp=yes
The unit ships without a User=, so systemd starts mezhub as root unless you add one. No listener
needs a privileged port, so add a service account before you enable
the unit:
User=mezite
Group=meziteFROM docker.io/library/alpine:3.21
RUN apk --no-cache add ca-certificates tzdata
RUN addgroup -S -g 10001 mezite && adduser -S -u 10001 -G mezite mezite
COPY --from=builder /bin/mezhub /usr/local/bin/
USER mezite
EXPOSE 3025 3080 3023 3024If you believe you have found a security vulnerability in Mezite, please report it privately to our security team. Do not disclose details publicly until we have had a chance to investigate and ship a fix.
Mezite is a new project. No CVEs have been reported or assigned. We will track and disclose any vulnerabilities here as the project matures.
Security advisories are published on this page and emailed to customers under support. Enterprise customers receive priority pre-disclosure of CVEs ahead of public release.
Mezite is self-hosted software. Your data never leaves your infrastructure. We do not collect telemetry, usage analytics, or personally identifiable information from your Mezite deployment.
The mezite.com website uses minimal analytics to understand traffic patterns. No cookies are used for tracking. We do not sell or share any data with third parties.
Mezite is proprietary software distributed under the Mezite Commercial License. The Managed and Self-Hosted tiers grant a right to use the signed binaries; reverse engineering, decompilation, and redistribution are not permitted. Enterprise customers may receive a separate Source-Available License under NDA.
The software is provided "as is", without warranty of any kind. See Pricing for tiers and Enterprise Source Access for source-available terms.
Learn how to configure role-based access control with labels, deny rules, and template variables.
Read GuideConfigure audit logging, session recording, and retention policies for SSH sessions.
Read GuideSource-available license terms for security teams who need to audit, scan, or pentest the Mezite codebase under NDA.
Read Terms