Static SSH keys
In a traditional setup, a user’s public key is copied into authorized_keys on every server. The server checks whether the presented key appears in that file.
This works for a small number of machines, but it creates a distribution problem: every access change requires updates on every affected server, and the key itself does not express an issuer, identity policy, or expiry time.
SSH certificates
An SSH certificate is signed by a certificate authority. A server trusts the CA public key instead of storing every user’s public key. The certificate contains the signed public key, certificate type, validity interval, and principals.
The basic trust relationship is:
server trusts CA public key
CA signs user's public key
server verifies certificate and principalNokku’s SSH CA signs user certificates for nk and host certificates for nokkud.
What this changes
- Access policy is represented by principal assignments rather than copied public keys.
- A certificate has an explicit lifetime.
- A certificate principal can identify a Nokku user independently of the Linux username.
- A single CA trust entry can cover many users and servers.
Certificates are not a replacement for authorization policy. The server still needs to check whether the certificate principal is allowed to use the requested Linux account.
Revocation is not deletion
Disabling a user prevents new issuance and changes future authorization. An already-issued certificate remains valid until it expires unless the server’s current authorization policy rejects it. For this reason, CA TTLs are an important part of the access design.