What Are SSH Keys and Why SSH Certificates Are Better

SSH keys are the dominant method for authenticating administrative access to servers, cloud infrastructure, and network devices. While most IT teams use them, few have a complete picture of where all their keys live.

According to a report by Venafi, over 90% of organizations lack a full inventory of their SSH keys. When a key is compromised, lost, or tied to a departed employee, teams often have no reliable way to identify every system that key touches — let alone remove it. Rather than  a configuration error that gap is a structural limitation of SSH keys.

This article explains what SSH keys are and how authentication works, then walks through why key management at scale can lead to audit and security problems that static keys cannot solve on their own. It also covers SSH certificates, a more secure alternative that address both failure modes, and how enterprise PKI infrastructure can serve both SSH and network access authentication from a single platform.

What Are SSH Keys?

SSH keys are cryptographic credentials used to authenticate connections over the Secure Shell (SSH) protocol. Instead of a password, access is granted based on proof that the connecting party holds a specific private key. That proof is generated mathematically, never transmitted directly, and cannot be replicated without the private key itself.

SSH keys come in pairs: a private key and a public key. The private key stays on the client — the machine initiating the connection. The public key is placed on the target server in a file called authorized_keys. When a client connects, the server uses the public key to issue a cryptographic challenge that only the matching private key can answer. If the response is correct, access is granted.

SSH keys are used in many scenarios:

• Developer access to cloud and on-premise servers
• Server-to-server authentication for automated jobs and scripts
• CI/CD pipeline access to deployment targets
• Service account authentication for infrastructure tooling
• Remote access by IT administrators and contractors

The private key is the entire basis of trust. If it is compromised, anyone holding it can authenticate as the key’s owner. Most key pairs have no built-in expiry date, which means a compromised key stays valid until someone manually removes the corresponding public key from every server it was added to.

How SSH Key Authentication Works

SSH key authentication follows a structured challenge-response process. No password or secret is transmitted across the network at any point.

1. Connection request: The client initiates an SSH connection to the server and identifies which public key it will use to authenticate.
2. Challenge generation: The server checks its authorized_keys file. If the public key is present, the server generates a random challenge and encrypts it using that public key.
3. Challenge response: The client decrypts the challenge using its private key, signs a hash of the decrypted value with the same private key, and sends the signature back to the server.
4. Verification: The server verifies the signature using the public key. If the signature is valid, it confirms the client holds the matching private key.
5. Session established: The server grants access and the encrypted session begins.

This process has a few key characteristics. The private key never leaves the client. The server never receives the private key, and the challenge is different every time — so replaying a captured session does not help an attacker.

Many environments use ssh-agent to hold private keys in memory during a session, so users authenticate once rather than entering a passphrase on every connection. In automated workflows, keys often have no passphrase at all — a convenience that becomes a risk if the private key file is exposed.

SSH Key Algorithms: RSA, ECDSA, and Ed25519

When generating an SSH key pair with ssh-keygen, the choice of algorithm determines the key’s cryptographic strength, size, and compatibility with target systems. Three algorithms are in common use:

RSA

RSA is the oldest and most broadly compatible SSH key algorithm. Modern deployments should use a minimum key size of 2048 bits; 4096 bits is the standard recommendation for new RSA keys. RSA keys are accepted by virtually every SSH server in production. The tradeoff is size — RSA-4096 keys are substantially longer than equivalent-security keys from modern algorithms.

ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) uses elliptic curve cryptography to produce shorter keys at comparable security levels. A 256-bit ECDSA key offers security roughly equivalent to a 3072-bit RSA key. Some security researchers have raised concerns about the quality of random number generation in certain ECDSA implementations, making Ed25519 the preferred alternative for new deployments.

Ed25519

Ed25519 is the recommended algorithm for new SSH key generation. It uses a modern elliptic curve design that is fast, produces compact keys, and avoids the implementation weaknesses associated with some ECDSA curve parameters. The ssh-keygen command for a new Ed25519 key pair is:

ssh-keygen -t ed25519 -C “your-comment-here”

For environments that must support older systems with limited cipher support, RSA-4096 remains the compatibility choice. For everything else, Ed25519 is the current standard.

SSH Key Management: Where the Problems Start

SSH keys work straightforwardly at small scale. For example, with one administrator, a handful of servers, and a known set of keys management is manual but workable. At enterprise scale, that model breaks in predictable ways.

Key Sprawl: The Inventory Problem

Each developer or administrator typically has one or more key pairs. Each key pair may be authorized on dozens or hundreds of servers. In organizations with thousands of servers and hundreds of users, the matrix of keys-to-servers is essentially unmanageable without dedicated tooling. Without a complete inventory, an organization cannot determine which systems a compromised key can access, cannot verify that a departing employee’s access was fully removed, and cannot demonstrate access controls to an auditor with any confidence. Research from Venafi based in an industry survey shows large organizations have, on average, over 7,000 root access orphan keys, each representing a potential backdoor into their systems.

No Expiry: Keys That Never Expire Are Never Rotated

SSH keys have no built-in expiration mechanism. A key generated five years ago is just as valid today as the day it was created unless it is manually removed it from every server where it was authorized. In practice, that rarely happens on a consistent schedule, and keys from contractors, former employees, and deprecated service accounts persist because no automated process forces their removal.

Key accumulation is what distinguishes SSH key authentication from password policies or certificate-based access. A certificate can be issued with a validity window of 24 hours, 7 days, or 90 days. When it expires, access ends — automatically, without manual intervention. An SSH key does not expire unless you build and operate an entirely separate rotation workflow.

Revocation Without Centralization

Revoking an SSH key means finding every authorized_keys file on every server where that key appears and removing the entry. There is no equivalent of a certificate revocation list, no central authority to notify, and no protocol mechanism for a server to check whether a key should still be trusted. It is a search-and-delete operation that has to be executed across the entire server fleet.

For a 50-server environment with a disciplined access management process, this is achievable. For a 5,000-server environment with multiple teams managing access, manual revocation is not reliable. The core issue is that the SSH key trust model does not scale, meaning organizations need a better solution.

SSH Keys vs. SSH Certificates vs. Password Authentication

The three common approaches to SSH authentication have different security and operational profiles. The right choice for an organization depends on scale, audit requirements, and existing identity infrastructure.

Password authentication is unsuitable for server access in most enterprise environments. SSH keys improve security over passwords but replace the password management problem with a key inventory problem. SSH certificates address both by adding expiry, centralized trust, and identity binding that keys lack.

It’s also worth emphasizing that SSH keys create far more key entries, because every person-to-server relationship requires a separate authorized_keys entry. Scaling from 100 users and 100 servers means potentially managing 10,000 key entries. With SSH certificates, servers trust any certificate signed by the Certificate Authority (CA) — the administrator adds the CA public key once to each server, and every certificate the CA issues is automatically trusted. Adding a new user adds one certificate issuance action, not one action per server.

How SSH Certificate Authentication Works

SSH certificate authentication replaces the per-server authorized_keys file with centralized trust in a CA. The SSH server trusts any certificate signed by the CA. The client presents a certificate instead of a raw public key, and the server validates the signature — no authorized_keys lookup required.

The process works as follows:

1. CA setup: An administrator configures SSH servers to trust a specific CA by adding the CA public key to the TrustedUserCAKeys configuration directive. This is a one-time operation per server.
2. Certificate issuance: When a user needs access, they submit their public key to the CA. The CA signs it and returns a certificate that includes: the user’s identity, the list of principals (allowed usernames), a validity window (e.g., 8 hours, 24 hours, 7 days), and any access restrictions.
3. Authentication: The user presents the certificate during the SSH handshake. The server verifies the CA’s signature and checks that the certificate is within its validity window and that the requested principal is allowed.
4. Automatic expiry: When the certificate’s validity window closes, access automatically ends. No manual key removal, no per-server cleanup.

Certificates can carry additional attributes — source IP restrictions, forced commands, and custom extensions — that raw SSH keys cannot express. And because the CA signs each certificate with the user’s identity at issuance time, there is a clear audit record of who was granted access to what, and for how long.

For a detailed walkthrough of the SSH certificate authentication process and how it compares to raw key authentication, see the SecureW2 guide to SSH certificate authentication.

One PKI for SSH, Wi-Fi, and VPN

The infrastructure to issue, sign, and manage certificates is already present in many organizations. Most enterprise IT teams already operate Public Key Infrastructure (PKI) for certificate-based authentication. 802.1X network authentication — the standard used to control access to Wi-Fi and wired networks — relies on digital certificates issued by a CA. VPN certificate authentication works the same way. SSH certificates require exactly the same infrastructure: a CA that issues signed certificates, identity provider integration to bind certificates to user accounts, and lifecycle management to issue, renew, and revoke certificates as users join and leave the organization.

Solutions from SecureW2 are certificate-native. The SecureW2 Dynamic PKI platform acts as the certificate authority for 802.1X device certificates for Wi-Fi and VPN, and t can also issue SSH user and host certificates. There is no separate SSH CA to deploy and operate — it’s all bundled together in one solution. The identity provider integrations already in place — Entra ID, Okta, Google Workspace — govern certificate issuance across every use case.

The operational benefit is direct: when a user is deprovisioned in Entra ID, their access to the Wi-Fi network, the VPN, and SSH-protected servers all terminate through the same certificate authority.For organizations already using a cloud-native PKI for network access, extending that infrastructure to cover SSH is operationally straightforward — and it closes the key inventory and revocation gaps that SSH keys cannot address on their own.

Replace SSH Keys With Certificate-Based Authentication

SSH key authentication is not going away. It is deeply embedded in server infrastructure, DevOps tooling, and sysadmin practice. But the limitations that make key management painful at scale are not fixable by adding more SSH key management tooling — they are structural. Keys have no expiry, no centralized trust, and no revocation mechanism that works across a large server fleet without manual work.

SSH certificates address each of those problems directly: built-in expiry, CA-based trust that requires only one configuration change per server, and identity binding that connects access to the user’s current status in your directory. Combined with short certificate lifetimes, certificate-based SSH access gives security teams an audit trail that key-based access cannot.

SecureW2 Cloud PKI provides the managed certificate authority infrastructure to issue SSH certificates alongside 802.1X certificates for Wi-Fi and VPN access. The same platform, the same IdP integrations, the same lifecycle management. If your organization already uses SecureW2 for network access authentication, extending certificate-based identity to SSH does not require a separate deployment.

Schedule a demo to see how SecureW2 PKI infrastructure handles SSH certificate issuance and lifecycle management, or contact SecureW2 to discuss how certificate-based SSH authentication fits your access architecture.