Investigate & document: personal SSH key on bastion for SSO-down backend access (offline cache)

[guimard]

Question / investigation

In a bastion/backend deployment, can a user keep a personal SSH key in
their home directory on the bastion so that bastion→backend connections keep
working even when the SSO (LemonLDAP::NG) is down, leveraging the existing
offline authorization cache? If so, document it (English admin docs and
update the French EBIOS study under doc/security/).

If feasible, users would presumably run plain ssh user@backend from the
bastion (not ob-ssh), since ob-ssh requires the portal online to mint its
ephemeral cert.

Preliminary analysis (conditional answer)

The answer depends on the deployment mode — this is the core thing the doc must
make explicit:

Cert-vouching / max-security mode → NOT possible (by design)

• The bastion's sshd uses TrustedUserCAKeys + AuthorizedKeysFile none: it
  only accepts LLNG-signed certs, never a plain key.
• ob-ssh mints an ephemeral cert via /pam/bastion-cert — requires the
  portal online; there is no offline cache for cert minting (the per-session
  voucher is not cacheable either).
• On backends, ob-ssh-principals (AuthorizedPrincipalsCommand) only emits a
  principal when the cert key-id is bastion=<id>;user=<u>;…. A plain user key
  is rejected before PAM even runs.

Key-based mode (PAM "Mode C", key + LLNG authorization) → possible, with caveats

• Here backends authorize a user's public SSH key via /pam/authorize, and
  the offline authorization cache can keep that working when LLNG is
  unreachable (this is exactly the README "Continue SSH key authentication when
  LLNG server is unavailable" feature).
• So: user's public key registered/known to LLNG, private key in ~/.ssh on the
  bastion, and ssh user@backend succeeds from cache during an SSO outage —
  if the backends are deployed in key-mode, not cert-vouching mode.

Deliverables

1. Decision + investigation: confirm the key-mode path end-to-end against a
   lab (SSO up, then SSO down → cached authorization still admits the key).
   Confirm what registers the user's public key in LLNG and how the cache TTL /
   high-risk-service TTL apply.
2. English documentation (likely doc/offline-mode.md and/or
   doc/bastion-architecture.md / doc/pam-modes.md): a clear
   "What works offline" vs "What needs LLNG online" matrix, and an explicit
   note that a personal key on the bastion is an opt-in, key-mode-only
   resilience pattern — never available in cert-vouching mode.
3. French EBIOS update (doc/security/): the trade-off raises the threat
   level — long-lived private key resident on the bastion, weaker
   bastion-vouching/source-address guarantee, and the bastion's role as the
   mandatory audited point of passage is partially eroded. Update the relevant
   risk entries (e.g. R-S6 bastion compromise, R-S18 session-record bypass) and
   add a dedicated note in doc/security/02-ssh-connection.md /
   99-risk-reduce.md.

Security note

This documents a degraded-but-available posture for outages, not a
recommended default. The doc must frame it as a conscious trade-off (resilience
vs. the ephemeral-cert security model) so operators choose deliberately.

Acceptance criteria

• Feasibility validated in a lab for key-mode (with evidence).
• English docs state precisely when it works and the trade-offs.
• French EBIOS study updated with the revised risk assessment.

[guimard]

First idea: give more long-term ephemeral keys to ob-ssh