Product
Issue short-lived SSH certs from your SSO. Audit everything.
Linux Identity replaces static SSH keys with SSO-tied short-lived certificates, captures every sudo invocation at the PAM level, and writes it all to a tamper-evident audit chain. The host agent is not in the SSH critical path — if it crashes, your engineers still get in.
Architecture
Three moving parts. Your IdP issues identity. The control plane issues certs. The host agent captures audit events. None of the three are in each other’s critical paths.
Host agent
A lightweight daemon on each Linux host. Registers the host with the control plane, installs the CA public key into sshd config, captures sudo invocations via a PAM module, and uploads audit events to the append-only log.
- Not in the SSH critical path
- Cosign-signed binary, SBOM published
- Graceful sudo degradation on network loss
Control plane
The multi-tenant SaaS backend. Holds the SSH CA in a managed KMS, verifies OIDC tokens, evaluates access policy, issues short-lived SSH certificates, and stores the append-only audit log. Postgres row-level security enforces tenant isolation on every query.
- SSH CA private key in a managed KMS — never on disk
- Row-level security on every Postgres query
- Append-only audit role (no UPDATE / DELETE)
SSO / Identity provider
Your existing OIDC-compatible IdP: Okta, Google Workspace, or Microsoft Entra. We verify ID token signatures against the IdP’s JWKS. We never store passwords. Engineers authenticate once per cert TTL; the cert does the rest.
- No password storage
- PKCE + nonce verified on every token
- Groups and roles read from SSO claims
Lifecycle of an SSH session
From command to connection in under a second. Here is exactly what happens.
- 1
Engineer runs linuxid ssh prod-web-01
The CLI checks for a valid local SSH certificate. If none exists or the cert is expired, it opens an OIDC flow against your configured IdP. No password prompt. No static key to manage.
- 2
CLI hits the control plane
The CLI sends the OIDC ID token to the Linux Identity control plane along with the target hostname. The control plane verifies the token signature against the IdP’s JWKS, checks nonce, iss, aud, and expiry.
- 3
Control plane verifies identity + evaluates policy
Once the token is verified, the control plane checks whether this user is allowed to access this host based on your configured access policies. Groups and roles are read from the verified SSO claims — no separate role database to maintain.
- 4
KMS-signed cert issued with a 4-hour TTL
The control plane calls a managed KMS to sign an SSH certificate (ECDSA P-256). The CA private key never leaves the KMS. The cert encodes the user’s verified email as the principal, the allowed hosts, and a 4-hour expiry by default. TTL is configurable from 1 minute to 24 hours via the admin portal.
- 5
SSH proceeds via standard OpenSSH
The CLI presents the cert to ssh. The sshd on the target host validates the cert against the trusted CA public key installed during agent enrollment. No online lookup, no control plane in the critical path. The connection is indistinguishable from a normal SSH login.
- 6
Session metadata logged to the audit chain
The host agent captures the SSH session start, every sudo invocation, and session end. Each event is written to an append-only audit log with a sha256 hash chain. The agent then uploads and deletes the local cache. Tampering is provable.
What you get on day one
Five outcomes, not five features.
Replace static SSH keys across the fleet
Each engineer gets a short-lived SSH cert tied to their SSO identity. No more key rotation ceremonies, no more off-boarding sweeps, no “who owns this key?” questions.
Audit chain that holds up in front of auditors
Every sudo invocation is captured at the PAM level with a tamper-evident hash chain. The evidence export maps rows to SOC 2 CC6.x controls so your auditor can verify directly — no manual assembly.
Sudo policy that doesn’t break root
The sudo plugin enforces policy but degrades gracefully. If the agent can’t reach the control plane, sudo continues to work via OS defaults. Only event logging is degraded. Root access is never blocked by a network blip.
Zero-trust for the next engineer who joins
New hire authenticates through your existing IdP. A cert is issued automatically once they’re in the right group. No manual key distribution, no waiting for someone to add an authorized_keys entry.
No Teleport-sized bill or deployment project
Five-minute install. $25/host/mo on Team with volume discounts. No proxy fleet, no per-region auth service, no enterprise contract negotiation. You call the install script, the agent registers, and you’re done.
What’s coming
We ship in milestones. M1 is the SSH core. M2–M4 are committed on the roadmap; timelines shift based on design partner feedback. We don’t put dates on items more than one milestone out.
M1 — SSH core (shipping)
- SSH CA in a managed KMS (ECDSA P-256)
- Short-lived cert issuance tied to Okta / Google / Entra
- Host agent with sudo capture (PAM module)
- Append-only audit log with sha256 hash chain
- 5-minute install script
- Hosted control plane (Team tier)
M2 — JIT access
- Just-in-time access requests with approval workflow
- Time-boxed elevated certs (1-hour escalation window)
- Slack + email notifications for approvers
- Audit trail on every approval and denial
M3 — Compliance reports
- One-click SOC 2 evidence pack (CC6.1, CC6.2, CC6.3, CC7.2)
- Drift detection: alert when a host loses agent coverage
- Continuous control monitoring against policy
- Auditor-shareable report format (PDF + raw JSON)
M4 — Non-human identity (NHI)
- SSH certs for CI/CD pipelines and service accounts
- Short-lived machine certs tied to workload identity (GitHub Actions OIDC, cloud workload IAM)
- Audit trail on non-human SSH sessions identical to human sessions
Five minutes from now, your first cert could be issued.
Request access and we’ll walk you through the install. Founder-led onboarding, no sales deck.