fix(ssh-ca): bound /ssh/sign with a rate limit and a per-user quota

[guimard]

Closes #63. Stacked on #89 → #88 → #87.

The mechanism

/ssh/sign explicitly permits reusing a label for the same key, and each
re-signature calls _updateKrl on the superseded serial. Nothing rate-limited
it and the core has no limiter for plugin REST routes.

Every call forks ssh-keygen twice and rewrites the entire KRL as a
read-modify-write, so the cost grows with the KRL: the amplification is
superlinear. Each appended serial is then loaded by every sshd on every
backend. A shell loop from one authenticated user is a denial of service
against the whole fleet, not just the portal.

Chosen mechanism

I had flagged that this one needed a decision on the limiter. Going with the
option that adds no dependency and no new storage, since the alternatives
(CrowdSec, a dedicated bucket store) both cost more than the problem is worth
here:

A fixed hourly window counted in the user's own session. The session store
is already shared across nodes, so the count is cluster-wide for free. Two
racing signatures can under-count by one — the store has no atomic increment —
which is irrelevant for a limit whose job is to bound a loop, not to be exact.
Say the word if you'd rather have CrowdSec here and I'll swap it.

Setting	Default	Over the limit
sshCaSignMaxPerHour	20	429 + Retry-After, SSH_CA_SIGN_RATE_LIMITED
sshCaMaxCertsPerUser	20	409, SSH_CA_CERT_QUOTA_EXCEEDED

0 disables either. A non-numeric value falls back to the default rather than
to unlimited, so a Manager typo cannot quietly remove a limit.

The rate limit is charged first, before parsing, the key policy check or
any fork — an abusive caller must not be able to make the portal do the work.

A re-signature of a key the user already holds replaces its record, so it
never grows the set and is not counted against the quota: someone sitting at
the cap can still rotate. A new key needs a /ssh/myrevoke first.

The KRL is deliberately not capped

Refusing to record a revocation because the file is large is a silent
fail-open — the certificate stays usable. Bounding the two inputs bounds the
KRL instead, without ever dropping a revocation.

Note on the issue's second point

The claim that /ssh/certs does a full session scan holds only for backends
without a native searchOnExpr; the Apache::Session::Browseable::* backends
implement it as an indexed query. Nothing to do there.

Tests

New t/04-SSHCA-limits.t, 32 assertions: the quota, the re-signature
exemption, freeing a slot by revoking, the 429 with its header and body, the
limit being per user, the window rolling over, 0 disabling both, and a
malformed setting falling back to the default rather than to unlimited.
ssh-ca 602 total, pam-access 769 — green.

https://claude.ai/code/session_01GfBG36HfzjGy8W9rJQbxBL

[guimard]

Verified: updatePersistentSession (Run.pm:665) persists both session copies; respHeaders/spliceHdrs carry Retry-After; the $resign exemption matches _storeCertificate's replace-by-fingerprint semantics (a re-signature under a different label also replaces, so the quota can't be bypassed).

Two nits:

1. With disablePersistentStorage the counter is never written and the rate limit is silently inactive — consistent with the rest of the plugin (certs aren't persisted either) but worth a README note.
2. "Charged before parsing" in the commit message isn't quite true — _jsonBodyOrReject parses first (cheap, harmless).

Also a conservative edge: re-signing an expired cert at the quota is refused although it wouldn't grow the active set (the expired record is replaced by fingerprint). Fine, but worth knowing.

[guimard]

Both nits documented in the README (commit 22b9da2), plus the edge you flagged:

1. disablePersistentStorage — added a callout: the counters live in the user's session, so with persistent storage off neither limit applies. Consistent with certs not being persisted either, but a deployment relying on the rate limit needs to know.
2. Expired-cert re-signature at the quota — documented. $resign is only set from active records (the loop skips revoked and expired), so re-signing an expired key at the quota is refused like a new one. Left as is: the conservative direction.

On the commit message: correct, _jsonBodyOrReject parses first. The message is already pushed; I have not rewritten it since the branch is under review — say the word if you would rather it be amended.

https://claude.ai/code/session_01GfBG36HfzjGy8W9rJQbxBL