How SSHKing works
People and servers prove who they are with short-lived SSH certificates instead of copied keys. This guide covers what the certificates are, how to set up servers and laptops, and what to do when keys rotate or someone leaves.
Two kinds of certificate
Every environment has two certificate authorities (CAs). They appear as the two key tags on the environment page.
| User certificate | Server certificate | |
|---|---|---|
| Signed by | The environment's User CA | The environment's Server CA |
| Proves | This key belongs to alice | This really is web1.acme.internal |
| Kept on | The laptop, next to the private key: ~/.ssh/id_ed25519-cert.pub | The server: /etc/ssh/ssh_host_ed25519_key-cert.pub |
| Name inside | The person's username | The server's host names |
| Lifetime | Hours. Limited by the organisation, environment and server; renewed automatically when you ssh | 30 days by default, up to 90 days. Renewed every day |
| Checked by | The server (sshd) | The laptop (ssh) |
| Replaces | Copying public keys into authorized_keys | Typing yes to an unknown fingerprint |
What happens when you connect
- Your laptop shows its certificateIt was signed by the environment's User CA for your username.
- The server checks the signatureThe User CA must be trusted on that server, and your key must not be revoked.
- The server checks the accountYour username must be allowed for the account you asked for, for example
deploy. - Your laptop checks the serverAt the same time, the server shows its host certificate and your laptop checks it against the Server CA.
Access lives in Members, not in the certificate
Who may use which server account isn't written into the certificate. It comes from Members, at the organisation, environment, department or server level, plus the server accounts you choose there. Each server downloads this list every 5 minutes, so access changes don't need new certificates.
Set up a server
Who: an admin of the environment or department.
Before you start
- Root access, OpenSSH 8.2 or newer (Ubuntu 20.04+, Debian 11+, RHEL/Rocky/Alma 9+, Fedora, Amazon Linux 2023) and outbound HTTPS to
https://sshking.app. - Accounts: either turn on Create accounts on servers for the environment, or create the accounts yourself (for example
deploy) before people log in. See Server accounts below. - Keep your current way in, such as
authorized_keysor a console, until a certificate login works. Enrolling doesn't remove it.
Steps
- Add the serverOpen the environment, choose Add server, and enter its name, the host names people type after ssh, and optionally a department.
- Copy the enrol commandIt works once and expires after 24 hours. Create a new one on the server page if needed.
- Run it as root on the serverPick the server's system. The first line installs what the tool needs; the rest is the enrol command from step 2.
# as root (sudo -i) apt-get update && apt-get install -y curl openssh-server sudo curl -fsSL https://sshking.app/sshking-server -o /usr/local/bin/sshking-server \ && chmod 755 /usr/local/bin/sshking-server \ && sshking-server enroll https://sshking.app sshenr_…
Ubuntu 20.04 or newer, Debian 11 or newer. Needs outbound HTTPS to https://sshking.app.
- Give people accessUse Members on the server, its department, the environment or the organisation.
What enrolling installs
| File or item | Purpose |
|---|---|
/etc/sshca/device.token | The server's own credential, readable by root only |
/etc/sshca.conf | Service address and environment |
/etc/ssh/sshca_user_ca.pub | User CAs this server trusts (TrustedUserCAKeys) |
/etc/ssh/sshca_revoked_keys | Keys to refuse (RevokedKeys) |
/etc/ssh/sshca_principals/<account> | Usernames allowed for each account |
/etc/ssh/sshca_limits | How old a certificate, and the person's last confirmation, may be. Checked by /usr/local/lib/sshking/principals on every login (AuthorizedPrincipalsCommand) |
/etc/ssh/ssh_host_ed25519_key-cert.pub | The server's host certificate |
/etc/ssh/sshd_config.d/50-sshca.conf | The sshd settings that use the files above |
| Timers | sshking-sync every 5 minutes, sshking-host once a day |
Check it worked
sshd -T | grep -Ei 'trustedusercakeys|authorizedprincipals|hostcertificate' cat /etc/ssh/sshca_principals/deploy # who may log in as deploy systemctl list-timers 'sshking*' sudo sshking-server sync # refresh now instead of waiting
The server turns green in the app once it has checked in.
Server accounts
People log in to Unix accounts on the server. Which accounts each person may use is set under Members (Server accounts). Leaving it empty means their own username.
| Setting (environment page) | What the server does on every sync |
|---|---|
| Create accounts on servers | Creates any allowed account that doesn't exist, with a home directory and no password. Accounts are never deleted: when access is removed, the principals file is emptied and logins stop. A list of created accounts is kept in /etc/sshca/created-accounts. |
| Give admins sudo | Writes /etc/sudoers.d/sshca with passwordless sudo for admins' and owners' own accounts. Shared accounts never get sudo from here. The file is rebuilt every sync, so sudo goes away when someone stops being admin. |
| Sudo for one person | Turn on sudo for a membership under Members (any level), or use Give sudo on this server on a server page. That person's server accounts get passwordless sudo on the servers it covers. Each server page lists everyone with sudo and why. |
Prefer shared accounts? Give everyone the login deploy under Members and create that one account when you build the server image. Nothing else needs creating.
Quick renewal
Short certificates are safer: a stolen laptop's certificate stops working within hours. With quick renewal people don't notice them expiring, because ssh gets a fresh one by itself.
- Run sshking-user login onceIt adds a rule to
~/.ssh/configthat runssshking-user auto <host>before each connection. - ssh renews when neededFor servers you can reach through SSHKing, a certificate with less than 10 minutes left is replaced silently. Other hosts, such as GitHub, are left alone.
- Every so often, confirm it's youWhen the confirmation interval has passed, the terminal shows a code and opens the browser. Approve it (signed in with your email) and the connection carries on.
| Setting | Organisation | Environment | Server |
|---|---|---|---|
| Certificates last up to | The ceiling (24 hours by default) | User certificates last, under Settings | Shorter for this server |
| Confirm it's you every | 24 hours by default | More often | More often |
| Renew automatically | On by default | Can turn off | Can turn off |
Who decides
The strictest setting wins. Servers enforce the limits themselves: the issue time and the last confirmation are inside the signed certificate, and sshd refuses certificates that are too old for that server, even if they haven't expired.
sshking-user status # certificates and whether automatic renewal is on sshking-user setup-ssh # add the ~/.ssh/config rule (sshking-user login does this) sshking-user setup-ssh --remove # take it out again
Set up your laptop
Who: everyone who logs in. Works on macOS and Linux. On Windows, use WSL with Ubuntu.
Once
- Accept your invitationOpen the email and sign in with the same address.
- Install the helper
sudo apt-get update && sudo apt-get install -y curl openssh-client sudo curl -fsSL https://sshking.app/sshking-user -o /usr/local/bin/sshking-user sudo chmod 755 /usr/local/bin/sshking-user
Ubuntu 20.04 or newer, Debian 11 or newer.
- Sign in from the terminalIt shows a code. Approve the same code in your browser.
sshking-user login
sshking-user login registers your key (it creates ~/.ssh/id_ed25519 if you don't have one), writes your certificate, adds the Server CA to ~/.ssh/sshca_known_hosts, points ~/.ssh/config at it, and loads the key into ssh-agent if one is running.
Every day
| Command | What it does |
|---|---|
ssh deploy@web1 | Connect as usual |
sshking-user login | Renew by hand. Usually not needed: ssh renews automatically and asks you to confirm in the browser now and then |
sshking-user envs | List the environments you can use |
sshking-user status | Show your certificates, when they expire and whether automatic renewal is on |
sshking-user rotate-key | Make a new key and revoke the old one |
One key works everywhere: sign-in gets a certificate for each environment you can use, kept in ~/.ssh/sshca/certs, and ssh picks the right one for each server.
Rotating CA keys
Rotation replaces a CA's signing key. Admins find these actions on the key tags of the environment page.
Rotate key (staged, the normal choice)
- A new key is publishedIt shows as Not signing yet. Servers trust it within 5 minutes; laptops learn it on their next sshking-user login.
- It starts signing after the stage period24 hours by default. The old key shows as Still trusted.
- The old key retiresOnce every certificate it signed has expired, it stops being trusted.
Nobody needs to do anything.
Rotate immediately
The same, without the waiting period. People's current certificates keep working. For the Server CA, ask everyone to run sshking-user login once so their laptop learns the new key before servers renew their host certificates (within a day).
Key compromised
Replaces the key and revokes the old one at once. Everything it signed stops working. Revoke on a key tag does the same for that key.
| Compromised key | Admin | Everyone else |
|---|---|---|
| User CA | Nothing more. Servers refuse old certificates within 5 minutes | Run sshking-user login for a certificate from the new key |
| Server CA | Renew host certificates now instead of waiting for the daily timer: systemctl start sshking-host on each server | Run sshking-user login so the laptop stops trusting the old key |
Automatic rotation
Set Rotate keys every (days) in the environment settings, and staged rotations happen by themselves.
Revoking keys and access
| Situation | Who | What to do | Result |
|---|---|---|---|
| Change what someone can reach | Admin | Members: change the role or server accounts, or Remove | Servers update within 5 minutes; no new certificate needed |
| Someone leaves | Admin | Remove them everywhere they're listed. Check Access from higher up on server and department pages: removing someone from the organisation doesn't remove access given directly on an environment, department or server | Refused everywhere within 5 minutes |
| Lost or stolen laptop | The person, or an admin | Person: SSH keys, Remove the key (revokes it in all their environments). Admin: environment, Recent certificates, Revoke (that environment only) | The key is refused within 5 minutes and can't get new certificates |
| Routine key change | The person | sshking-user rotate-key | New key and certificate; the old key is revoked. Old files are kept as *.retired-<date> |
| Revoked by mistake | Admin | Environment, Revoked keys, Allow again | Works again after the next sync |
Good to know
- A server that can't reach the service keeps its last access list until it reconnects. Short certificate lifetimes limit how long that matters.
- Laptops stop trusting a compromised Server CA key only after they run
sshking-user login. - Revoking a certificate revokes its whole key, not just that one certificate.
- Servers count towards your plan; people, organisations and environments don't.