Nokku has three product components. The core is the control plane, nk runs on a user’s workstation, and nokkud runs on a target server. SSH remains the data path between the user and the target.
Components
nokku
The core is the control plane and API. It stores workspaces, identities, targets, access assignments, daemons, and certificate authorities. It signs SSH and X.509 certificates and maintains daemon control streams.
nk
The CLI runs on the workstation. It authenticates the user or service account, synchronizes access data, creates a local key pair, obtains SSH certificates, generates SSH configuration, and opens the target connection through nk proxy.
nokkud
The daemon runs on a target server. It enrolls the server, synchronizes target metadata and principals, owns the SSH host key and host certificates, and serves an embedded SSH server that authenticates certificate-based logins against its local cache. It runs sessions with the target user’s privileges and records them.
SSH connection flow
When you run ssh ubuntu@server against a daemon-managed target, nk checks (and if needed renews) your SSH certificate, then opens a TCP connection to the daemon’s embedded SSH server. The daemon verifies your certificate against the trusted CA, checks its cached principal map for the requested Linux account, and drops privileges to run the session as that user.
The core serves identity and certificate operations, but it is not a TCP proxy for the connection path. There’s a detailed, step-by-step walkthrough in How an SSH Connection Works.
Communication channels
nkto core: HTTPS API requests.nokkudto core: authenticated, persistent bidirectional ConnectRPC control stream.nkto target: TCP connection opened bynk proxyto the daemon’s embedded SSH server.- Core to
nokkud: principal, certificate, daemon, and session notifications over the control stream.
The control connection is outbound from the target server. The SSH data path is inbound to the daemon’s SSH port on the target.
Two ports, two directions
The daemon keeps an outbound control connection to the core, so a server behind a strict firewall can still be managed by Nokku. But because the daemon serves SSH directly, its SSH port (4022 by default) must be reachable by your users.
When the core is unavailable
The embedded SSH server keeps authenticating from its on-disk principal cache. That cache represents the last synchronized policy, so policy changes cannot reach the server until the daemon reconnects.
nk can use cached target data and an existing certificate when the core cannot be reached. It cannot issue a new certificate or refresh access while offline.