Introducing Mezite: Self-Hosted SSH Access

SSH Keys Are Broken

SSH key-based authentication was a significant improvement over passwords. But at scale, the operational reality has become untenable. Public keys accumulate on servers with no record of who put them there. Keys never expire. When someone leaves the organization, their keys linger on servers for weeks or months because nobody is sure which servers they had access to.

A typical mid-size organization has thousands of public keys scattered across hundreds of servers, with no central inventory, no rotation policy, and no audit trail showing who authenticated when and to which host.

How Certificates Fix This

SSH certificates are built into the OpenSSH protocol. Instead of trusting individual public keys, servers trust a Certificate Authority (CA). The CA signs short-lived certificates for users on demand. Each certificate carries the user’s identity, their permitted principals, and a validity window. When the certificate expires, access stops.

No public keys on servers. No authorized_keys files to manage. No key rotation process. When a user leaves, you revoke their ability to get new certificates. You do not need to hunt down every server they ever accessed.

What Mezite Does

Mezite is a self-hosted SSH access platform. It sits between your users and your SSH infrastructure, authenticating every connection with short-lived certificates, enforcing role-based access control, and recording a complete audit trail of every session.

It is focused exclusively on SSH. The project was originally broader in scope — database proxy, Kubernetes access, application proxy — but we made the deliberate decision to strip all of that away and focus on doing one thing extremely well. SSH access is the foundation of infrastructure access, and it deserves a dedicated tool.

Architecture Overview

A Mezite deployment has three components:

1. Auth Service — Manages users, roles, certificate authorities, and access policies. Exposes a gRPC API on port 3025.
2. Proxy Service — Terminates client SSH connections on port 3023 and routes them to the appropriate agent. HTTPS on port 3080 for the web interface and API.
3. Agent — Runs on each target node. Connects back to the proxy via a reverse tunnel on port 3024, so no inbound ports are required on the target.

Both services are compiled into a single signed mezhub binary. For small deployments, you run one process. All state lives in PostgreSQL or SQLite — nothing else required.

# Download the signed release binary
curl -fsSL https://releases.mezite.com/latest/mezite-linux-amd64.tar.gz \
| tar -xz -C /usr/local/bin/

# Start the server (auto-runs migrations on first start)
MEZITE_CLUSTER_NAME=access.example.com \
MEZITE_DB_HOST=localhost MEZITE_DB_NAME=mezite \
MEZITE_DB_USER=mezite MEZITE_DB_PASSWORD=secret \
mezhub

# Join a node
MEZITE_AUTH_ADDR=access.example.com:3025 \
MEZITE_PROXY_ADDR=access.example.com:3024 \
MEZITE_JOIN_TOKEN=<join-token> \
mezd start

# Connect via SSH
msh login --proxy=access.example.com --user=alice
msh ssh --login=ubuntu staging-web-01

Closed Source, Audited Where It Matters

The software that brokers SSH access to every server in your organization should not be casually exposed to opportunistic scanning. We ship Mezite as signed binaries and container images — controlled distribution, signed builds, no public source.

That does not mean you have to take our word on what the binary does. Enterprise customers receive a source-available license under NDA, with rights to read, audit, statically scan, and pentest the codebase. Reproducible builds let you verify the binary you run matches the source you reviewed.

For everyone else: signed releases, published SBOMs, third-party audit summaries, and responsible disclosure on a schedule. Closed source is a distribution choice, not a transparency one.

Getting Started

The fastest path to a running Mezite cluster is the Quickstart Guide. It walks through installation, configuration, and connecting your first node in under five minutes.

For a deeper understanding of the system, start with the Architecture page, then explore the SSH Access Guide.

Try the free hosted tier for evaluation, or talk to us about a self-hosted license — and if your security team needs source-level review, ask about Enterprise Source Access.