This page is for people who haven’t spent years in front of a terminal. It explains the pieces Nokku builds on, so the rest of the docs make sense whether you’re a seasoned sysadmin or someone who just needs to know what the product actually does.
What SSH is
SSH (Secure Shell) is how you log into and control a server over a network. You run a command on your laptop, it opens a secure, encrypted channel to another machine, and you end up with a terminal on that machine as if you were sitting in front of it.
Two programs are involved:
ssh(the client) runs where you are (your laptop or CI machine).sshd(the SSH daemon) runs on the server and accepts incoming connections. “Daemon” is just the technical word for a background service that listens for connections.
When you type ssh ubuntu@web-01, the @ splits the Linux username (ubuntu) from the server name (web-01).
Keys: proving who you are
To log in, the server needs to know it’s really you. The modern way uses a key pair:
- A private key that only you have (a secret file on your machine).
- A public key that you hand to servers.
The math lets the server prove you hold the private key without you ever sending it. That proof is called a signature. Anyone with your public key can check a signature, but only you can create one.
The old way: authorized_keys
Traditionally, to let someone in, you copied their public key into a file called authorized_keys on every server. At login, sshd checked whether the presented key was in that file.
That works for a handful of machines, but it falls apart at scale:
- Every access change means editing a file on every affected server.
- A key carries no context: no expiry, no owner, no issuer.
- Keys pile up long after people have left.
The Nokku way: certificates instead of copied keys
Instead of copying every person’s public key to every server, a certificate authority (CA) signs a short-lived certificate for each person. A server only needs to trust the CA’s public key, a single trust entry that covers everyone.
The trust chain looks like this:
server trusts the CA's public key
CA signs the user's public key into a certificate
server verifies the certificate is signed by the CAA certificate is a signed wrapper around a public key. It carries facts a bare key doesn’t:
- Validity: exactly when it expires. Nokku issues short-lived certificates, so a leaked certificate is only usable for a short window.
- Principal: the Linux username(s) the holder may use.
- Issuer: which CA signed it, so the server knows who to trust.
Your private key never leaves your machine. Only your public key gets signed into a certificate.
Servers need proof too: host certificates
The first time you connect to a server, ssh usually asks “are you sure you want to continue connecting?” because it has no way to know the server is genuine. That prompt is called TOFU (trust on first use).
A host certificate fixes this the other way around: the server presents a certificate proving its host key is signed by the workspace CA. Your client already trusts that CA, so it can confirm the server is genuine without the first-connection warning.
How Nokku ties it together
nkruns on your workstation. It signs you in, gets a short-lived user certificate, and generates thesshconfiguration.nokkudruns on each server. It runs its own SSH server, holds a host certificate, trusts the workspace CA, and answers the “who’s allowed on this Linux account?” question from its local cache.- You still use plain
ssh. From your point of view nothing about the command changes. The machinery happens behind the scenes.
For a step-by-step version, see the Quickstart. For every term defined in one place, see the Glossary.