SSH certificate authority

The brokered session keeps keys off the connecting device. The SSH certificate authority finishes the job on the host side: instead of distributing static authorized_keys, Kutrion runs a per-organization SSH CA and issues short-lived certificates on demand. A host trusts the CA once, and from then on it accepts any unexpired, principal-matching certificate Kutrion mints — and nothing else.

How it works

• One CA per organization. Each org has its own certificate authority keypair. The CA is created and rotated by an org admin; any org member can read the CA public key, which is safe to publish.
• The CA private seed is protected like a credential. It is envelope-encrypted: a random data key encrypts the seed, and that data key is wrapped by the master key. The seed is never stored in plain text and never leaves the process in the clear.
• Short-lived user certificates, issued on demand. When you connect, Kutrion signs a certificate for your login. Its lifetime is configurable up to 8 hours, the hard ceiling. Each certificate stamps the principals (remote usernames) it is valid for and carries its own validity window, so it self-expires — there is nothing to revoke by hand. The certificate’s key ID is set by Kutrion, not by the requester, so every certificate traces back to the member who asked for it.
• Members sign only the login names an admin assigned them. An org admin can issue a certificate for any principal. A member can issue one only for the remote usernames an org admin assigned to them on the SSH certificate authority page; a member with none assigned cannot issue a certificate at all. Nothing is derived from a member’s email address or their single sign-on profile, and each login name belongs to one member of the org. Assigning a shared account such as root to a member is an explicit admin decision, recorded in the audit log.
• Agent forwarding is off unless asked for. A certificate permits a terminal, X11 and port forwarding, and user rc files by default. Agent forwarding is added only when the request explicitly opts in.
• No static keys to manage. Because hosts trust the CA rather than a list of individual keys, you never edit authorized_keys to add, remove, or rotate a person’s access.

Trust the CA on a host

Each host trusts the org’s trust file: one line per CA the host should accept. Outside a rotation it holds just the current CA. Get it by running kt sshca trust or copying it from SSH certificates in the web app, then distribute it to your hosts with your configuration management. Hosts do not fetch it from Kutrion themselves.

# 1. On each target host, write the trust file:
sudo install -m 644 kutrion_ca.pub /etc/ssh/kutrion_ca.pub

# 2. In /etc/ssh/sshd_config, point sshd at that file:
TrustedUserCAKeys /etc/ssh/kutrion_ca.pub

# 3. Reload sshd so the change takes effect:
sudo systemctl reload sshd

The host now accepts any unexpired Kutrion-issued certificate whose principal matches the login user. No per-user key has to be present on the host.

To trust the CA for a single account without touching sshd_config, add the same keys to that account’s ~/.ssh/authorized_keys as cert-authority lines (the web app shows them ready to copy).

Use an issued certificate

When Kutrion generates the keypair for you, the private key comes back once in OpenSSH format. Save it as kutrion-id_ed25519 (mode 600) with the certificate beside it as kutrion-id_ed25519-cert.pub, then run ssh -i kutrion-id_ed25519 user@host; ssh picks up the certificate next to the key.

Rotation

Rotation is staged so no host is cut off. A host only accepts certificates from the CAs in its trust file, and Kutrion cannot change that file for you, so the new CA has to reach every host before it signs anything.

1. Stage a next CA. It appears in the trust file next to the current one but signs nothing yet.
2. Refresh the trust file on every host. Hosts now accept certificates from either CA.
3. Promote the next CA, confirming that every host has the refreshed file. New certificates are signed by it. The old CA becomes the previous CA and stays in the trust file, so certificates it already issued keep working.
4. Retire the previous CA when nothing needs its certificates, then refresh the trust file again. Once a host has the refreshed file it refuses that CA’s certificates, even unexpired ones.

A staged CA that you decide not to use can be discarded the same way. Each step is an org-admin action and is written to the audit trail.

Issuance is self-expiring and audited

Every certificate carries its own validity window and expires on its own; there is no separate revocation list to maintain for routine access. Kutrion keeps an append-only issuance ledger of every certificate it mints — serial, key id, principals, validity window, and fingerprint — for inventory and audit. Creating the CA, each rotation step (staged, promoted, retired), and issuing each certificate are all written to the audit trail.

Where to go next

• SSH broker overview — keep keys off the connecting device too.
• Connecting to hosts — create a connection profile and open a session.
• Audit logs — review CA creation, rotation, and every issued certificate.