SSH keys and SSH certificates both authenticate users and systems using public-key cryptography, but they rely on different trust models. SSH keys establish trust by storing authorized public keys in each server’s authorized_keys file, while SSH certificates use a trusted Certificate Authority (CA) to verify identities and grant time-bound access centrally. This distinction has significant implications for scalability, security, auditing, and operational management.
The operational impact of those different trust models becomes apparent as environments grow. The problem does not arrive as an event. It accumulates. A new engineer joins and needs access to the staging environment, so their key gets added to a dozen servers. An external contractor completes their engagement, and their key is not removed because no one tracks which servers it was on. Automation pipelines generate key pairs for deployment scripts, and those keys outlive the pipelines they were built for. Three years later, a team that once had clean, intentional access ends up with hundreds of keys sitting across the server infrastructure, and no reliable inventory of who owns them.
A 2024 State of Zero Trust and Encryption Study highlighted that 57% of respondents considered managing SSH keys to be painful and difficult. The same study reported that this figure had fallen to 27% as awareness and management practices improved, yet SSH key management remains a significant challenge in many organizations. The improvement reflects a better understanding of the problem, but not its resolution. The risks of unmanaged keys persist regardless of how well the problem is recognized.
What makes this difficult to catch early is that nothing breaks. Servers respond, pipelines run, deployments complete. The access problem is invisible until it becomes a security or compliance event. An audit asks for a list of who has access to production. An offboarding review cannot confirm that a former employee’s credentials have been removed. An incident investigation traces lateral movement back to a key that should have been revoked two years prior. By that point, remediation is no longer as simple as removing a single key. It becomes an exercise in reconstructing trust relationships and access histories that were never centrally tracked.
This is where the distinction between SSH keys and SSH certificates becomes important. Both provide strong authentication based on public-key cryptography, but they rely on fundamentally different trust models. Those differences affect how access is granted, managed, audited, and revoked, particularly as the environment grows. This blog explains how SSH keys and SSH certificates work, where their trust models diverge, and why those differences become increasingly significant at enterprise scale.
What Are SSH Keys
An SSH key is a pair of cryptographically linked files: a private key and a public key. They are generated together as a matched set and serve a single purpose, proving identity without sending a password over the network.
The private key stays on the machine it was created on. It must never be copied, shared, or transferred. It is the only file that can complete an authentication challenge issued by the server, and its security is the entire basis of trust in this model.
The public key is the counterpart that gets distributed. It carries no sensitive information and can be placed on any server that needs to grant access. On each server, it is stored in a file called authorized_keys, typically located in the home directory of the target user account. That file is a simple list: one public key per line, each representing an entity that the server is willing to authenticate.
The connection between the two keys comes from asymmetric cryptography. The private key is used to generate a cryptographic signature, and only the corresponding public key can verify that signature. Knowing one does not allow anyone to derive the other, and a valid signature can only be produced by the holder of the private key. That relationship is what makes key-based authentication secure without requiring a shared secret.
How SSH Key Authentication Works
The authentication sequence follows a defined handshake. Each step has a specific purpose, and the process is designed so that the private key proves its existence without ever being exposed.
The user’s public key is copied into the authorized_keys file on each target server. Depending on the organization, this may be done by an administrator, by the user directly if they have server access, or through an automated provisioning script. This is the act that establishes trust between that user and that specific server.
- The user initiates a connection. The SSH client signals to the server which public key it intends to use for authentication.
- The server checks its authorized_keys file. If the submitted public key is present and permitted for the target user account, the server proceeds with authentication.
- The client signs the authentication request, including the session identifier, using its private key and sends the signed request to the server. The private key never leaves the client.
- The server verifies the signature using the stored public key. A valid signature confirms that the client possesses the corresponding private key, and authentication succeeds.
That sequence completes the authentication handshake, but the trust model it creates has characteristics worth examining closely.
The server trusts the SSH key because it is listed in the authorized_keys file. That trust has no expiration date and no central record. It persists until someone manually removes the key from that file.
The Operational Challenges of Manual SSH Key Management
The authentication process itself is secure. The challenges arise from how trust is established and maintained over time, especially when SSH keys are managed manually.
Every server maintains its own authorized_keys file, and every public key that needs access must be added, updated, or removed individually. As the number of users, servers, automation pipelines, and service accounts grows, this decentralized trust model becomes increasingly difficult to manage consistently.
Unlike many modern authentication systems, SSH keys have no built-in expiration. A public key remains trusted until it is manually removed from every server where it has been installed. If a user changes roles, leaves the organization, or no longer requires access, administrators must identify every server that trusts that key and remove it. Without a centralized inventory, that process is often incomplete.
The challenge extends beyond revocation. Organizations frequently struggle to determine who owns a particular key, why it was deployed, whether it is still being used, and whether it should continue to exist. SSH keys created for temporary projects, contractors, or automation workflows can remain active long after their original purpose has disappeared, increasing operational complexity and expanding the potential attack surface.
These limitations are not weaknesses in SSH’s cryptography. They are a consequence of a trust model in which each server independently decides which public keys to trust. As environments scale, organizations often look for ways to centralize those trust decisions, reduce manual administration, and improve visibility into SSH access. SSH certificates were designed to address many of these operational challenges.
What Are SSH Certificates
An SSH certificate is a public key that has been signed by a trusted Certificate Authority, commonly referred to as a CA. By signing the key, the CA binds identity and access information to it, creating a verifiable credential. Unlike a standalone public key, which contains no information about who owns it or how long it should be trusted, an SSH certificate can include identity attributes, validity periods, and access restrictions. The CA’s cryptographic signature ensures that this information cannot be modified without invalidating the certificate.
The certificate format used by OpenSSH is not the same as the X.509 format used for HTTPS websites. It is a purpose-built format defined in the OpenSSH PROTOCOL.certkeys specification. The two share the same concept of a CA vouching for a public key, but they are structurally different and not interchangeable.
An SSH certificate contains several fields beyond the public key itself. It includes a Key ID, an arbitrary string assigned at signing time that helps identify the certificate in logs and audit records. Organizations often use usernames, email addresses, employee IDs, or ticket numbers for this purpose. It also includes a principals list, which specifies the identities the certificate is authorized to represent. For user certificates, principals commonly correspond to operating-system usernames such as ubuntu, ec2-user, or admin.
It includes a validity window, with a start time and an end time expressed as Unix timestamps. Certificates can also contain extensions that grant specific capabilities, such as port forwarding, agent forwarding, or terminal access. It includes critical options, which are enforced constraints such as restricting the certificate to specific source IP addresses or limiting the session to a single command. And it includes the CA’s digital signature over all of the above, which is what ties everything together and prevents tampering.
The CA itself is simply an SSH key pair in a protected location. Its private key is used to sign user and host public keys. Its public key is distributed to servers once, via a single line in the SSH server configuration file. From that point on, any server configured to trust the CA can authenticate certificates signed by that CA, provided the certificate’s principals, validity period, and policy constraints are satisfied.
How SSH Certificate Authentication Works
The authentication sequence is similar to key-based authentication at the protocol level, but the trust decision works differently. Instead of checking whether the connecting key is listed on that specific server, the server checks whether the certificate was signed by a CA it trusts. The following steps describe how that process works:
- A CA key pair is generated, and its public key is distributed to each server once, using the TrustedUserCAKeys directive in the SSH server configuration file. This is a one-time setup step per server. No changes to this configuration are needed when new users are added or removed.
- When a user needs access, their public key is submitted to the CA for signing. The CA signs it using its private key and returns a certificate file. That certificate contains the user’s key, their identity, the principals they are authorized to authenticate as, and the validity window. The user’s private key does not change.
- The user initiates a connection. The SSH client presents the user’s certificate and proves possession of the corresponding private key by signing the authentication request and session identifier. Unlike traditional SSH key authentication, where the server receives a standalone public key, the client presents a certificate containing the public key along with the CA’s signature and associated identity information.
- The server checks whether the CA signature on the certificate is valid, using the CA public key it already holds from step 1.
- The server checks whether the certificate type is correct for user authentication.
- The server checks whether the current time falls within the valid-after and valid-before window embedded in the certificate.
- The server checks whether at least one principal listed in the certificate matches the target user account.
- If all of these checks pass, the server verifies the client’s signature using the public key extracted from the certificate. A valid signature confirms the client holds the corresponding private key. Access is granted.
- When the validity window closes, the certificate stops working automatically. The user must obtain a new signed certificate to regain access. The private key never leaves the client machine at any point in this process.
That is the structural difference from key-based authentication. The server does not need a pre-existing record of the user. Trust flows from the CA, not from a file on each individual server.
SSH Keys vs SSH Certificates: A Direct Comparison
The differences between SSH keys and SSH certificates are not limited to how authentication works at the protocol level. They extend to every stage of the credential lifecycle, from how access is granted on day one to how it is removed when it is no longer needed. The table below covers each of those dimensions directly.
| Dimension | SSH Keys | SSH Certificates |
|---|---|---|
| Trust model | Each server directly trusts individual public keys listed in its authorized_keys file | Each server is configured to trust one or more CAs and accepts certificates signed by those CAs |
| Credential format | Standalone public key | Public key with signed metadata and CA signature |
| Identity information | Optional comment field; not verified during authentication | Signed Key ID and principals are embedded in the certificate |
| Authorization | Access is granted when the public key is trusted by the server | Access is granted when the certificate is valid and the principal is authorized |
| Expiration | No built-in expiration; access remains valid until the key is removed | Built-in validity period enforced during authentication |
| Access provisioning | Public keys must be distributed to each server where access is required | Servers trust the CA; users receive certificates issued by the CA |
| Access removal | Public keys must be removed from every location where they are trusted | Access can be limited through short-lived certificates; certificates can also be revoked before expiration using a Key Revocation List (KRL) configured on each server |
| Credential rotation | Requires generating and redistributing new keys | Typically requires issuing a new certificate; the underlying key pair may be reused if organizational policy permits |
| Server administration | Requires maintaining authorized_keys entries across servers | Requires maintaining CA trust and certificate issuance |
| Auditability | Logs generally contain usernames and key fingerprints; ownership mapping may require external records | Certificates can include signed identity attributes, Key IDs, and serial numbers that improve traceability |
| Scalability | Management effort grows with the number of users, keys, and servers | Management effort shifts toward centralized certificate issuance and CA governance |
| Infrastructure requirements | No CA infrastructure required | Requires a CA key pair, certificate issuance process, and CA trust distribution |
| Typical use case | Small to medium environments, static access relationships, simple deployments | Large-scale environments, dynamic access management, and centralized identity governance |
The table makes clear that neither approach is universally superior. SSH keys remain a practical and secure choice in many environments. The gap is not in the credential itself, but in how consistently it is governed, rotated, and revoked across the infrastructure it protects.
How Encryption Consulting Can Help
At Encryption Consulting, we understand the challenges enterprises face in managing SSH keys at scale. Our solution, SSH Secure, is built to deliver end-to-end key lifecycle security, centralized visibility, and HSM-backed protection, ensuring that organizations can manage keys confidently without added complexity.
Some of the key features of SSH Secure include:
1. Centralized Visibility and Ownership Mapping
Through a combination of agent-based and agentless discovery, SSH Secure locates every SSH key across servers and user machines. All keys are stored in a unified inventory with ownership and usage details, eliminating orphaned keys and ensuring full accountability across the environment.
2. Automated Key Lifecycle Orchestration
SSH Secure automates the complete key lifecycle, covering secure generation, policy-driven rotation, and revocation. Keys can be rotated or revoked on demand or in accordance with organizational policies. For sensitive operations, SSH Secure can issue ephemeral session-bound keys that expire automatically. This centralized lifecycle management enforces least-privilege access, reduces the risk of compromise, and ensures keys do not remain valid beyond their intended use.
3. HSM-Integrated Protection
All private keys are generated and stored within HSMs. Keys are generated using strong cryptographic algorithms such as RSA-4096, ECDSA, and Ed25519, providing strong cryptographic protection, resistance against cryptanalytic attacks, and efficient performance.
4. Policy-Driven Control for Key Operations
All key operations, such as generation, approval workflows, rotation, and revocation, are enforced through policy-based controls. This ensures consistency across the environment, reduces manual errors, and maintains organization-wide security standards. Policies can be adapted to fit regulatory requirements or customized to support internal governance models.
5. Continuous Monitoring, Auditing, and Compliance Readiness
SSH Secure provides real-time monitoring of key activities with detailed event logging and built-in anomaly detection. Logs can be integrated with Splunk or Grafana Loki dashboards for advanced visualization, correlation, and alerting. Flexible audit capabilities include downloadable logs and detailed reports, giving security teams clear insights into key usage and overall posture. Centralized auditing with policy-based alerts enables proactive security management, rapid anomaly detection, and faster incident response.
Implementing HSM-backed SSH key management at enterprise scale involves more than choosing the right hardware. It requires discovery, lifecycle orchestration, policy enforcement, and ongoing visibility across a complex environment. At Encryption Consulting, we built SSH Secure to handle exactly that, delivering end-to-end key lifecycle security and HSM-backed protection without adding operational complexity.
Conclusion
SSH keys and SSH certificates solve the same problem at the cryptographic level. Both prove identity without sending a password over the network, and both rely on the same public key cryptographic operations. The difference is not in the strength of the cryptography. It is in what happens to access over time.
A key placed on a server three years ago by someone who no longer works at the organization is just as valid today as it was on the day it was added. The server has no way to know otherwise. That is not a flaw in the key. It is a consequence of a trust model that was designed for simplicity, not for lifecycle governance at scale.
The gap is not in the key itself. It is in how SSH keys are governed throughout their lifecycle. Centralized discovery, ownership mapping, policy-driven rotation, timely revocation, and continuous auditing significantly reduce the operational risks associated with unmanaged SSH keys, without requiring organizations to deploy and operate a Certificate Authority. For many enterprises, strengthening SSH key governance is the most practical and immediate step toward securing privileged access.
The organizations that have already absorbed the cost of unmanaged key sprawl through audit findings, incident investigations, or manual cleanup efforts have paid more than the tooling required to prevent it. The right time to establish governed SSH key management is before the inventory problem becomes unmanageable, not after.
