thim.dev/blog
SEP 2026 · 11 MIN READ

A key that expires by lunch

TL;DR: My passkey now mints a short-lived SSH certificate instead of me keeping key files around forever. There are two ways in, an ordinary terminal and the browser, both proving the same identity, and accounts and machines set themselves up. Nothing is exposed but one certificate-only door, and the whole thing is built from free pieces, Authentik and step-ca, rather than a turnkey product priced for companies.

Almost everything in the lab goes through one door now. A single sign-on, a passkey on my phone, and the same login gets me into the dashboards, the storage, the photos, all of it. I wrote about that door already. What I did not mention is the one login that had quietly refused to join: the terminal.

SSH was still running the way it has run for twenty years. Key files, generated once and living forever, copied from laptop to laptop and pasted into a list on every machine that should let me in. And if I wanted a shell from outside the house, a port open to the whole internet, waiting. It worked. It always works. That is exactly the problem with it.

§ The trouble with keys

An SSH key is a bearer secret. The machine on the other end does not know who you are; it knows that whoever holds this file is allowed in, and it will go on believing that until someone remembers to strike the file from every list it was ever added to. There is no name attached, no expiry, no way to ask "is this person still meant to have this." A key is a spare made once and never counted again.

For one person and one machine that is fine. The trouble arrives with the second machine, and the third, and then the day you want to let someone else in too. Now the same anonymous file has to be present in more places, and revoking it means visiting all of them, and you will not, because nobody does. The list only ever grows. Somewhere in most people's setups there is a key that opens a door for a laptop that was wiped two years ago.

What I actually wanted was the thing every other login already had. Prove who you are, with the passkey I already carry, and be let in for a little while. Not forever. Not to whoever holds the file. To me, until this afternoon.

§ Not the obvious product

There is a well-known product that does all of this out of the box: identity-aware SSH, browser and terminal, audit trails, the lot. I spent an evening with it before I found the catch. The single sign-on integration, the one feature that mattered, lives behind an enterprise licence priced for companies, not houses. The free tier speaks to exactly one identity provider, and it is not mine.

So the turnkey option was out, which is how most of the good projects start. The pieces to build it are all free and all standard. It just falls to you to make them agree with each other.

§ A certificate authority for the house

The fix for a key that never expires is a certificate that always does.

I stood up a small certificate authority, the same idea as the one that vouches for websites, except this one vouches for people logging into machines. When I want a shell, I run one command. A browser window opens, I approve it with the same passkey I use for everything else, and the authority hands back a signed certificate that drops straight into my SSH agent. Then it is plain ssh, exactly as before. The difference is that the certificate is good for about an hour. When the hour is up it is gone, and there is nothing on disk to steal, forget, or copy to the next laptop.

the same door as everything else in the house you a passkey, no file single sign-on cert authority your machines passkey who are you mints a certificate good for about an hour then it is plain ssh, until the certificate quietly expires your login mints the key; the key expires by lunch

The machines no longer keep a list of who is allowed. They keep one fact: they trust certificates signed by the house authority. Adding a new machine to the fleet is telling it that one fact, once. Nobody's individual key ever needs to touch it. The list that used to only grow does not exist anymore.

This is the whole shift, and it is worth saying plainly. A key answers the question "do you hold the secret." A certificate answers "who are you, and are you still allowed, right now." The first is a lock that never changes. The second is an ID checked at the door and handed back.

§ The account that isn't there until you arrive

There was a second, quieter piece of manual work hiding behind the keys: the accounts themselves. Traditionally every machine has its own idea of who its users are, created by hand, one at a time, on each box.

Mine no longer do. The same identity provider that holds the logins also acts as the directory the machines consult. Your user account does not exist on a given machine until the first time you log into it, and then it simply appears: home directory created on the spot, the right group membership, the right level of access, all decided centrally and applied on arrival. I do not provision accounts. I add a person to a group in one place, and every machine they are entitled to already knows them the moment they knock.

The machines hold up their end without me too. When a new one comes into being, whatever spun it up, it enrolls itself within moments: it learns to trust the house authority and how to consult the directory, and from that point it is a valid destination like any other. There is no step in my routine called "set up SSH on the new box," because there is no such step. I bring a machine into existence and it sorts out the rest, and on the rare occasion I change how any of this works, every machine quietly reconciles itself to the new way on its own.

§ The browser path

Not everyone who might need a shell wants to install a certificate client and learn a new command, and honestly some days I don't either. So there is a second way in that needs nothing at all: SSH in the browser.

It goes through the same front door as the rest of the house, the same passkey, the same sign-on. Click a link, get a terminal in a tab, already authenticated. There is nothing to install and nothing to configure, which makes it the obvious path for a quick look, and the obvious path for handing access to someone who should not have to become a systems administrator first.

§ One door for the terminal too

Which brings me to the part I am most pleased with, and the reason the internet-facing port is now closed for good.

The terminal has one public entrance. A single hardened door, and behind it, nothing but the ability to be pointed onward. It takes no passwords at all, only a valid certificate, and once you are through it you jump to whichever machine you actually wanted, with the same certificate proving you at every hop. The machines themselves are not on the internet. Their SSH is reachable only from inside, and the only way inside is through the one door.

the public internet ends here you with your certificate the one door cert only, no passwords a machine another another the same certificate, every hop the machines' own port is never exposed to the outside one way in; remove a person and every door shuts at once

The internet notices an open door quickly. Within hours of this one going up, it had already been knocked on more than a thousand times: a steady drip of automated attempts to log in as root, as admin, as whatever usernames the scanners keep lists of. Every single one was turned away at the lock, and not one got through. There was nothing for them to try. There is no password to guess, and a certificate is not something you can brute-force. They can hammer the door for as long as they like; it does not have a keyhole they know how to pick.

So consider what it now takes to give another person their own terminal access to the lab, from anywhere in the world. I add them to the directory. That is the entire task. They log in with their own passkey, the authority mints them their own short-lived certificate, they come through the one door, and the machines they are allowed on create their accounts as they arrive. No key file is generated, sent, or pasted anywhere. Nothing long-lived exists for them to lose.

And I can be precise about what "allowed on" means. Access is per machine, and being able to log in is a separate thing from being able to act as an administrator. I can hand someone a shell on exactly one box, with no special powers on it, without giving them the run of anything else. Each of those decisions is a membership in one central group, and the machines already understand what the groups mean, so I grant and revoke by adding and removing a name in one place, never by touching a machine. The day someone should no longer have access, I remove them, and every door shuts at once, everywhere, with no list to hunt through.

That last property is the one keys could never give me. Revocation that is a single action instead of a chore I will skip.

§ How the parts fit together

I have been describing the behaviour; here are the actual parts, because none of it is exotic and most of it was already running.

The hub is Authentik, the identity provider the rest of the lab already leans on. It holds my passkey and it is the one place any login is ever decided. For this it does three jobs at once. It runs the passkey prompt. It answers other services over OIDC when they ask who just signed in. And it publishes a directory over LDAP, so machines can look up who exists and which groups they belong to.

The terminal path adds a single new piece: a small SSH certificate authority, step-ca. It trusts Authentik over OIDC. Its login command bounces me to Authentik, I approve with the passkey, and it signs a short-lived certificate in return. Every host is told once to trust certificates from this authority and to take its accounts from the directory. After that a host needs no per-person setup at all.

The browser path adds nothing to the machines. A remote-access gateway that ships with Authentik does the SSH server-side, inside the session the passkey already opened, and streams a terminal into the tab. It needs no certificate, because it never leaves the world Authentik is already vouching for.

All of it reaches the internet through the edge I already had: a small VPS, its reverse proxy, and the encrypted tunnels back to the lab that I wrote about in leaving Cloudflare for a VPS I actually control. That edge publishes exactly two things, the certificate authority and the one public door, and keeps everything else where it cannot be reached.

you a passkey Authentik identity provider passkey · OIDC · LDAP sign in once step-ca SSH certificate authority browser gateway SSH in a tab OIDC: who is this? same session your machines trust the CA read the directory short-lived cert accounts, over LDAP two ways to a shell, one identity behind both

Two ways to a shell, one identity behind both, and every machine downstream reading the same directory. That is the whole architecture. The rest is configuration.

§ The shape, finally reaching the terminal

None of the individual pieces here are novel. A certificate authority is old. A single point of entry is old. Central accounts are old. What was satisfying was watching the shape that made the rest of the lab manageable finally close over the last thing that had resisted it: one identity, one door, and nothing long-lived left lying around to leak.

A key you hold forever is a liability you will eventually forget you own. A certificate that expires by lunch is not. The terminal used to be the exception to how I run everything else. Now it is just another thing behind the same door, and I can stop thinking about it, which is the whole point.