Linux Identity
Request access

Get started

Three commands. Five minutes. Real SSH governance.

Three people are involved in bringing Linux Identity online for the first time: the admin who configures your tenant, ops who enrolls each host, and the engineer who logs in. Each one runs a small, scoped piece. Full setup is ~one engineer-hour, mostly waiting for SSO config to propagate. Here’s exactly what each person does.

Request accessHow it works under the hood
01

Customer admin

~10 min

Your platform engineer setting up the company tenant.

  1. 01

    Request access at linuxidentity.com. We provision your tenant and email you a dashboard URL.

  2. 02

    Sign into the dashboard with your work SSO. The first sign-in becomes the tenant owner.

  3. 03

    Add your OIDC config — Okta / Google Workspace / Microsoft Entra. Three fields: issuer, client_id, client_secret. We store the client_secret AES-256-GCM-encrypted at rest.

  4. 04

    For each host you want to govern, click “Generate enrollment token.” Copy the value (starts with linuxid_), hand it to whoever runs ops on that host.

What this gives you

A working multi-tenant config. Your engineers authenticate via your existing SSO; no separate accounts to provision in our system.

02

Ops

~30 sec per host

Whoever installs Linux software on the fleet.

  1. 01

    SSH to the host one more time with whatever you use today. (After this enrollment, you’ll use linuxid ssh instead.)

  2. 02

    Install the signed agent binary:

    curl -fsSL https://install.linuxidentity.com/install.sh | sudo bash
  3. 03

    Register the host with the token from your admin:

    sudo linuxid-agent register \
  --token linuxid_<token-from-admin> \
  --control-plane-url https://api.linuxidentity.com
  4. 04

    Reload sshd so it picks up the new TrustedUserCAKeys (or pass --reload to the register command):

    sudo systemctl reload sshd

What this gives you

sshd on this host trusts the Linux Identity CA. Engineers can land via SSO-issued certs immediately. Existing key-based access still works in parallel until you remove it — nothing about this enrollment locks anyone out.

03

Engineer

1 min once + every SSH

Daily SSH user. One-time setup, then every login.

  1. 01

    Install the CLI on your laptop:

    curl -fsSL https://install.linuxidentity.com/install.sh | bash
  2. 02

    Log in once. Opens a browser, completes the SSO flow against your IdP, stores a short session token at ~/.config/linuxid/session.json (mode 0600):

    linuxid login --control-plane-url https://api.linuxidentity.com
  3. 03

    Every SSH after. Generates an ephemeral key, requests a 4-hour KMS-signed cert, drops you into the host:

    linuxid ssh alice@prod-web-01

What this gives you

SSO-tied, 4-hour, KMS-signed SSH certs. Every login lands in your tenant’s audit chain. No static keys to rotate, no ssh-add ceremony.

Common questions

The questions every Series-A/B platform engineer asks before pulling the trigger.

Do I have to remove existing SSH keys first?
No. The agent installs the Linux Identity CA into a drop-in at /etc/ssh/sshd_config.d/linuxid.conf — the rest of your sshd configuration is untouched. Existing key-based access keeps working during migration. Remove keys at your own pace.
What if the Linux Identity control plane is down?
sshd validates certs directly against the CA public key it received at enrollment — no online dependency for an established trust. Existing sessions continue. New cert issuance pauses until we’re back. See /security/ for the full failure-mode breakdown.
Can I trial without bringing my SSO admin in?
Yes — there’s a self-hosted Open Source tier free up to 5 hosts. You run the control plane yourself; we never see your audit data. See /pricing/ for the trade-offs.
How do I roll back?
On each host: remove the linuxid-agent and delete /etc/ssh/sshd_config.d/linuxid.conf, then sudo systemctl reload sshd. The host reverts to whatever auth it had before. Your audit log of what happened during the trial is yours to export from the dashboard.
How do I add hosts later?
Just repeat step 02. Generate one enrollment token per host in the dashboard, run linuxid-agent register on the host. The flow is identical whether you have 5 hosts or 5,000.
Do I need to maintain a policy file?
No. The admin dashboard manages the per-user allowlist. Module 2 ships JIT request flow on top — engineers can request elevated access through Slack / Teams / email / SMS with approver workflows.

Ready to try it?

Request access — we’ll provision a tenant and reply within 24 hours with the dashboard URL and your first enrollment token.

Request accessSee pricingHow it works