Shellius vs. a DIY SSH CA
OpenSSH has supported certificates since 2010. A CA is one ssh-keygen command, trusting it is one line of sshd_config, and signing is one more command. If you have not seen it done, this walkthrough builds one by hand. Shellius uses exactly those primitives — it shells out to ssh-keygen.
So the honest question is what you would have to build around them.
What the primitives give you
- Hosts trust one CA instead of many keys.
- Certificates expire.
- Principals limit which accounts a certificate can log in as.
For a handful of hosts and two or three trusted people, that may be all you need. Do it; it is a large improvement over authorized_keys.
What you end up building
| You will need | By hand | Shellius |
|---|---|---|
| Somewhere safe to keep the CA key, and a way to sign without everyone having it | A locked-down signing box and a wrapper script | CA key encrypted at rest, decrypted only while signing |
| Deciding who may get a certificate for what | A config file and code review | Access policies, with deny rules that beat allow rules |
| Approval for production | Chat messages | A request, an approver, a reason, a record |
| Revocation before expiry | Distribute a KRL to every host, reliably | Hosts ask the API on every connection |
| Knowing who accessed what | Grep auth.log on each host | One append-only audit log, and session recordings |
| Onboarding a host | Copy files, edit sshd_config, hope | One command that validates the config before reloading |
| People who do not live in a terminal | — | Browser terminal and RDP |
Revocation is where home-grown setups usually stop. A key revocation list only works if every host has the current copy, which is the same distribution problem authorized_keys had.
The cost of not doing it yourself
Shellius is a stateful service your logins depend on. It needs backups, upgrades and a break-glass path for when it is down. A shell script has none of those failure modes. For a very small fleet, that trade may not be worth it.