SSH certificate-based authentication and access control for DevOps

At a glance

What this is: This is a DevOps tutorial on configuring SSH certificate-based authentication, with the key finding that certificate-based access improves control and revocation compared with passwords.

Why it matters: It matters to IAM practitioners because SSH certificates sit at the intersection of human, workload, and privileged access, where lifecycle control and auditability determine whether access is actually governed.

👉 Read StrongDM's tutorial on SSH certificate-based authentication

Context

SSH certificate-based authentication is a way to replace static password entry with cryptographic trust for SSH access. In practice, that shifts the problem from secret reuse to certificate issuance, expiration, and revocation, which is an identity governance concern as much as a server configuration task.

For IAM and PAM teams, SSH access is a privileged access path that often spans people, service operators, and automation. The operational question is not whether certificates are stronger than passwords, but whether the organisation can govern who gets them, how long they live, and how quickly they are revoked when access changes.

Key questions

Q: How should teams govern SSH certificate-based access for privileged users?

A: Treat SSH certificates as privileged credentials with owners, expiry, and revocation rules. Disable password fallback on sensitive systems, restrict trusted principals, and record every issuance and login event. Without lifecycle governance, certificate-based access can still become standing privilege with better encryption but the same operational risk.

Q: Why do SSH certificates reduce risk compared with passwords?

A: SSH certificates reduce risk because they remove reusable passwords, narrow access to specific identities, and support time-bound trust. That lowers brute-force exposure and makes revocation more precise. The benefit only holds if the organisation actually enforces expiry and tracks who can issue or renew certificates.

Q: What breaks when SSH keys and certificates are not rotated or revoked?

A: When SSH credentials are not rotated or revoked, access can outlive the job, the vendor relationship, or the incident that should have ended it. That creates standing privilege, weakens audit confidence, and increases the chance that a compromised key can be reused across hosts.

Q: How can security teams know whether SSH certificate controls are working?

A: Look for short certificate lifetimes, documented revocation events, and complete logs showing who accessed which system and when. If certificates persist far beyond their intended use or revocation is manual and slow, the control is not governing access, only authenticating it.

Technical breakdown

SSH certificate-based authentication and key pairs

SSH certificate-based authentication builds trust on a public and private key pair rather than a shared password. The private key remains with the user, while the server validates the corresponding public key or certificate metadata during login. Certificates add control fields such as expiry, permitted principals, and source restrictions, which makes access narrower than a plain key. The important technical shift is that identity proof becomes cryptographic and centrally governed, instead of relying on reusable credentials.

Practical implication: treat SSH certificates as governed privileged credentials, not as a one-time setup choice.

Server-side SSH configuration for certificate trust

On the server, certificate-based SSH access depends on sshd configuration, especially whether public key authentication is enabled and password authentication is disabled. The server must also know which certificates or keys it trusts and which users they can represent. That trust boundary is what turns SSH from an open login path into a policy-enforced one. If the server-side trust store is loose, certificate authentication can still permit broad or unintended access.

Practical implication: harden sshd trust settings and keep the allowed principal set as narrow as the business need.

Rotation, revocation, and audit trails in SSH access

Certificate-based access only reduces risk when expiry, rotation, and revocation are part of the operating model. A long-lived key or certificate can still become standing privilege if nobody removes it after role changes or suspicion of compromise. Logging is equally important because SSH is often used in administrative paths where weak visibility creates blind spots in incident response. Centralised audit trails let teams connect access events to named identities and specific sessions.

Practical implication: pair SSH certificates with enforced expiry, revocation workflows, and session-level logging.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH certificate-based authentication is only as strong as the lifecycle behind it. Password removal does not solve access governance if keys, certificates, and principals are left to drift. The control question is whether the organisation can revoke access as quickly as it grants it and prove that the active trust set is current. Practitioners should treat certificate authentication as a lifecycle discipline, not a point solution.

Standing SSH trust is the real failure mode this tutorial tries to avoid. Static public keys and long-lived certificates can create the same exposure pattern as other unmanaged non-human credentials. The governance problem is not cryptography failure, it is persistence without review. Teams should think in terms of limited exposure windows, clear ownership, and explicit offboarding for SSH identities.

Certificate-based SSH access aligns with Zero Trust only when verification is continuous at the access boundary. SSH certificates can support narrow, time-bound privilege, but only if the issuing and revocation process is tightly governed. That makes this pattern relevant to both privileged user access and operational workload access. The practitioner takeaway is to align SSH certificate policy with identity lifecycle controls, not just server hardening.

SSH access is a privileged identity problem, not just an admin convenience problem. The article’s value lies in showing that identity control moves closer to the server boundary when passwords are removed. That improves auditability, but it also raises the bar for certificate issuance discipline, because the trust decision is now encoded into every session. Organisations should manage SSH certificates as part of PAM and access governance, not as isolated DevOps tooling.

Centralised audit trails are the difference between secure SSH and merely encrypted SSH. Certificate-based access without logs only hides privilege use behind stronger authentication. The broader identity lesson is that evidence matters as much as control, especially when the access path can reach production systems. Practitioners should insist on traceable issuance, revocation, and session records before they treat the model as governed.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• SSH certificate governance should be read alongside OWASP Non-Human Identity Top 10, especially the controls covering credential lifecycle and overprivilege.

What this signals

SSH certificates reduce one class of credential risk, but they do not remove the governance burden. If your programme cannot trace issuance, expiry, and revocation, certificate-based SSH becomes a cleaner authentication layer on top of the same lifecycle problem. That is why the control conversation should sit next to the Ultimate Guide to NHIs, not inside a narrow server-hardening checklist.

The practical signal for IAM teams is that privileged access is moving further into short-lived, policy-bound credentials. That favors organisations that can enforce ownership and auditability, and it exposes teams still relying on manual tracking or scattered key files.

Lifecycle debt is the hidden weakness in SSH access. When certificates are easier to issue than to retire, the programme accumulates trust it cannot explain. Teams should watch for that pattern and align certificate handling with the same governance discipline they apply to other NHI credentials.

For practitioners

• Replace password SSH with certificate-backed access Disable password authentication on privileged systems and require certificate-based login for interactive administrative access. Keep the trust configuration narrow so only approved principals can authenticate.
• Define certificate lifetimes and revocation triggers Set short validity periods for SSH certificates and document the exact events that force immediate revocation, including role changes, suspected compromise, and contractor offboarding.
• Centralise SSH audit logging Capture certificate issuance, successful logins, and denied attempts in a single reviewable log stream so incident response can reconstruct who accessed which host and when.
• Review file permissions on all SSH materials Restrict private keys, public keys, certificates, and the .ssh directory to the minimum required permissions so local exposure does not undermine certificate-based controls.

Key takeaways

• SSH certificate-based authentication improves SSH access control, but only when issuance, expiry, and revocation are governed as a lifecycle.
• The main security gain is reduced standing credential exposure, not the certificate format alone.
• Organisations should tie SSH certificates to audit trails and privileged access governance before treating them as a complete control.

Key terms

• SSH Certificate-Based Authentication: An access method that uses cryptographic certificates rather than passwords to validate SSH sessions. It strengthens identity assurance by binding access to a key pair, certificate metadata, and server trust rules, while also creating governance duties around expiry, revocation, and logging.
• Standing Privilege: Persistent access that remains available beyond the period when it is genuinely needed. In SSH environments, standing privilege often appears as long-lived keys, certificates, or trusted principals that are never retired, making revocation slow and exposure windows unnecessarily wide.
• Certificate Revocation: The process of invalidating a credential before its natural expiry so it can no longer be used to authenticate. For SSH, revocation must be fast enough to matter operationally, otherwise a compromised or stale certificate remains a live path into sensitive systems.

Deepen your knowledge

SSH certificate-based authentication, rotation discipline, and privileged access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising SSH controls across DevOps and operations teams, it is worth exploring.

This post draws on content published by StrongDM: How to Configure SSH Certificate-Based Authentication (Tutorial). Read the original.