How host access works

The design principle is that hosts do not ask the directory anything at login time. Authorization happens when a credential is issued; the machine only verifies a signature.

That is not a compromise for simplicity's sake. It means logins keep working while Cardinal is down, credentials expire on their own, and a compromised host cannot enumerate anybody, none of which is true of a host holding a directory bind.

Logging in

cardinal ssh web-01.prod
cardinal ssh web-01.prod -l deploy   # a local account other than your own
cardinal ssh web-01.prod -print      # print the certificate, do not connect

That borrows a passkey ceremony through the console, asks Cedar may this person log into this host, and as whom, and issues a certificate lasting minutes whose principals encode the answer. sshd validates it against TrustedUserCAKeys. No network call to Cardinal happens on the host, and nothing is written to disk: the certificate goes into ssh-agent.

An access token cannot do this: policy requires a device-bound credential for SSH certificate issuance, and the refusal names that rule.

Signing in from the machine you are on

A terminal cannot perform a passkey ceremony, so it borrows one, and there are two ways to get the answer back.

Where the browser is here, cardinal ssh opens it and the approval returns to a listener on this machine. Nobody can talk you into approving somebody else's terminal, because the approval could not reach them.

Where it is not (which is the ordinary case of administering a server over SSH) the command prints a code instead:

  Approve this terminal from any device with a browser:

    https://id.example.com/cli-login
    code: BXFD-7KQN

  waiting…

Open that on a laptop or a phone, sign in, and approve. The code names the request; it is not the credential, which never leaves the terminal.

The command works out which to use. -auth loopback or -auth device forces one, for the cases it cannot see: a multiplexer that outlives the SSH session it started in, a remote desktop where the browser really is here.

Approve only a code you are looking at. The second flow is the one somebody can talk you into: anyone who gets you to approve their code has signed their terminal in as you. The approval screen shows the address the request came from as the server saw it, never a name the terminal chose, because a name it chose could say anything.

What it replaces

FreeIPA's HBAC, and the pile of authorized_keys files that configuration management copies around and nobody is sure are still live. A host is a directory entity, so "which machines" is group membership rather than a new kind of object.

Windows

Client-only, and not close to changing. Passkeys, OIDC and OpenSSH work; there is no managed-host path and no domain join, because the agent needs systemd's userdb, sudoers and sshd configuration.