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 certificateServer certificate
Signed byThe environment's User CAThe environment's Server CA
ProvesThis key belongs to aliceThis really is web1.acme.internal
Kept onThe laptop, next to the private key: ~/.ssh/id_ed25519-cert.pubThe server: /etc/ssh/ssh_host_ed25519_key-cert.pub
Name insideThe person's usernameThe server's host names
LifetimeHours. Limited by the organisation, environment and server; renewed automatically when you ssh30 days by default, up to 90 days. Renewed every day
Checked byThe server (sshd)The laptop (ssh)
ReplacesCopying public keys into authorized_keysTyping yes to an unknown fingerprint

What happens when you connect

  1. Your laptop shows its certificateIt was signed by the environment's User CA for your username.
  2. The server checks the signatureThe User CA must be trusted on that server, and your key must not be revoked.
  3. The server checks the accountYour username must be allowed for the account you asked for, for example deploy.
  4. 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_keys or a console, until a certificate login works. Enrolling doesn't remove it.

Steps

  1. Add the serverOpen the environment, choose Add server, and enter its name, the host names people type after ssh, and optionally a department.
  2. Copy the enrol commandIt works once and expires after 24 hours. Create a new one on the server page if needed.
  3. 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.

  4. Give people accessUse Members on the server, its department, the environment or the organisation.

What enrolling installs

File or itemPurpose
/etc/sshca/device.tokenThe server's own credential, readable by root only
/etc/sshca.confService address and environment
/etc/ssh/sshca_user_ca.pubUser CAs this server trusts (TrustedUserCAKeys)
/etc/ssh/sshca_revoked_keysKeys to refuse (RevokedKeys)
/etc/ssh/sshca_principals/<account>Usernames allowed for each account
/etc/ssh/sshca_limitsHow 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.pubThe server's host certificate
/etc/ssh/sshd_config.d/50-sshca.confThe sshd settings that use the files above
Timerssshking-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 serversCreates 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 sudoWrites /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 personTurn 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.

  1. Run sshking-user login onceIt adds a rule to ~/.ssh/config that runs sshking-user auto <host> before each connection.
  2. 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.
  3. 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.
SettingOrganisationEnvironmentServer
Certificates last up toThe ceiling (24 hours by default)User certificates last, under SettingsShorter for this server
Confirm it's you every24 hours by defaultMore oftenMore often
Renew automaticallyOn by defaultCan turn offCan 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

  1. Accept your invitationOpen the email and sign in with the same address.
  2. 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.

  3. Sign in from the terminal
    sshking-user login
    It shows a code. Approve the same code in your browser.

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

CommandWhat it does
ssh deploy@web1Connect as usual
sshking-user loginRenew by hand. Usually not needed: ssh renews automatically and asks you to confirm in the browser now and then
sshking-user envsList the environments you can use
sshking-user statusShow your certificates, when they expire and whether automatic renewal is on
sshking-user rotate-keyMake 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)

  1. 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.
  2. It starts signing after the stage period24 hours by default. The old key shows as Still trusted.
  3. 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 keyAdminEveryone else
User CANothing more. Servers refuse old certificates within 5 minutesRun sshking-user login for a certificate from the new key
Server CARenew host certificates now instead of waiting for the daily timer: systemctl start sshking-host on each serverRun 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

SituationWhoWhat to doResult
Change what someone can reachAdminMembers: change the role or server accounts, or RemoveServers update within 5 minutes; no new certificate needed
Someone leavesAdminRemove 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 serverRefused everywhere within 5 minutes
Lost or stolen laptopThe person, or an adminPerson: 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 changeThe personsshking-user rotate-keyNew key and certificate; the old key is revoked. Old files are kept as *.retired-<date>
Revoked by mistakeAdminEnvironment, Revoked keys, Allow againWorks 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.