Extend SSO & device identity to SSH

Traditional SSH relies on static, long-lived private keys stored on disk, which makes them easy to copy, rarely rotated, manually distributed, and prone to uncontrolled sprawl. Worse, they provide no cryptographic binding between the user and the device actually initiating access.

Smallstep replaces static SSH keys with short-lived SSH certificates issued only after SSO and device identity verification, and bound to non-exportable TPM or Secure Enclave keys. Certificates expire automatically and are renewed only when trust is re-established, eliminating persistent SSH credentials from the environment entirely.

Smallstep integrates directly with your IdP—such as Okta, Entra, or Google—to make SSH access identity-native instead of key-based. The user initiates access with step ssh login, authenticates through browser-based SSO, and Smallstep issues a short-lived SSH certificate.

That certificate encodes the user’s identity, group membership, allowed Unix usernames, permitted hosts, and a strict validity period, and is used automatically by the SSH client via ssh-agent. SSH identity stays continuously aligned with the IdP, with no local passwords and no static keys to manage.

Smallstep can optionally require both user and device authentication for SSH access instead of trusting user identity alone. The private key is generated and stored in a TPM on Windows or Linux systems or in the Secure Enclave on macOS, making it non-exportable by design.

During certificate issuance, the device must prove its hardware identity, and SSH certificates are issued only to attested machines. This blocks compromised hosts from impersonating trusted ones, prevents user credentials from being reused on unmanaged laptops, and defeats attacks involving cloned disks or virtual machines. SSH access becomes explicitly bound to both the user and the device.

No. Smallstep works entirely with standard, unmodified OpenSSH—there’s no proprietary SSH stack or custom agent in the path. On the server side, you add a trusted user CA key, enable SSH certificate authentication, and optionally use NSS or PAM modules for ephemeral users.

On the client side, users only need the step CLI and the standard ssh-agent. There are no custom daemons, proxies, or plugins to deploy. Your existing SSH ecosystem stays intact; Smallstep replaces only the brittle, static key management model.

Smallstep removes the manual work that has traditionally made SSH brittle and error-prone. There are no public keys to collect, no private keys stored in user home directories, no authorized_keys files to manage, and no manual onboarding or offboarding processes.

It also eliminates long-lived root or admin keys and the need to vault SSH keys altogether. Access is granted through short-lived certificates that expire in hours, ensuring permissions disappear automatically without cleanup tasks or human intervention.

Privileged access is granted only when it’s needed and only for a strictly limited time. An administrator authenticates through SSO and device attestation, and Smallstep issues a just-in-time SSH certificate.

That certificate encodes precise constraints—permitted Unix usernames, specific hosts, optional command restrictions, and an explicit expiration timestamp. Policy determines who can obtain which level of access, and when the certificate expires, privileged access disappears automatically.

Yes. SSH certificates can carry rich authorization context directly inside the credential itself. They can encode allowed hosts, user principals, group-based privileges, sudo constraints, time-of-day restrictions, maximum session duration, and optionally device identity.

Authorization is enforced cryptographically at connection time instead of being scattered across host-level configuration files, making access both more precise and easier to reason about.

Smallstep synchronizes identities directly from your IdP using SCIM or API integrations, turning SSH access into a just-in-time operation rather than a pre-provisioned one. Ephemeral Unix users are created automatically at login, IdP groups are mapped to server roles, and host-level accounts are removed once certificates expire.

Servers no longer need permanent user accounts defined in advance. Access exists only for the lifetime of the certificate and disappears automatically when that trust window closes.

Smallstep removes the attack primitives that make SSH abuse possible in the first place. There are no reusable SSH keys, no persistent private keys to steal, and no agent-forwarded long-lived credentials.

Access is granted through short-lived certificates bound to both the user and the device, with host principals restricting exactly which systems a certificate can reach. Short lifetimes sharply limit dwell time, and lateral movement becomes extremely difficult even if a single device is compromised.

Every SSH action under Smallstep produces a complete, cryptographically verifiable audit trail. Each session records who authenticated via the IdP, which device identity was used, which SSH certificate was issued, which host was accessed, and when the session started and ended, with optional command-level logging.

Auditing becomes deterministic and tamper-resistant because there are no shared credentials and no ambiguity about identity. Every action is tied to a specific user, device, and certificate.

Smallstep SSH is not a standalone system—it operates as part of a unified identity fabric. It ties into hardware-attested device identity, user identity validated through SSO, workload identity enforced with mTLS, network identity via EAP-TLS and VPN mTLS, and application identity through ZTNA and mTLS.

SSH becomes just another authenticated service governed by the same Zero Trust principles, policies, and cryptographic controls as the rest of the environment, rather than a special case with its own trust model.

Yes. Smallstep SSH operates consistently across heterogeneous environments, including Linux servers in AWS, GCP, Azure, and OCI, on-prem virtual machines and bare metal, Kubernetes nodes, edge and IoT Linux devices, and ephemeral CI runners.

SSH certificates can carry workload metadata such as cloud instance IDs, enabling environment-aware policies that adapt access controls to where and how a system is running.

Security is preserved because trust is anchored in hardware and continuously re-evaluated. Private keys cannot be exported from the TPM or Secure Enclave, SSH certificates expire quickly, and revocation prevents new certificates from being issued.

If hardware is tampered with, device attestation fails. If a user is suspended, SSO access stops immediately. Even stolen hardware cannot be used to access infrastructure because both the user and the device must remain valid at the time of access.

Yes—in most Zero Trust deployments, bastion hosts are no longer a hard requirement. When access is based on attested identities and just-in-time certificates, identity replaces network chokepoints.

Organizations can allow direct SSH access to internal hosts, eliminate credential storage on bastions, and remove single points of compromise. ZTNA or MASQUE tunnels can still be used when network routing or isolation is required, but bastions become optional tools rather than critical identity gatekeepers.