SSH Keys: What They Are, How They Work, and Why They Matter for Security

SSL certificates and SSH keys are built on the same mathematical foundation. Both use asymmetric cryptography, both involve a public key that can be shared openly and a private key that must never leave the holder’s control, and both solve the same fundamental problem: how do two parties that have never met verify each other’s identity over a network neither controls?

The differences lie in what they authenticate and how trust is established. An SSL certificate authenticates a server to a browser, and it depends on a Certificate Authority to verify and sign it. An SSH key authenticates a user or system to a server, and it requires no CA at all. The server simply stores the user’s public key, and authentication is a cryptographic proof that the user holds the matching private key.

This guide covers how SSH keys work at the protocol level, why the authentication mechanism is stronger than passwords, the key types and algorithms available and which to use, how to generate and deploy keys correctly, and the security practices that separate a well-managed SSH key infrastructure from one that accumulates untracked access over time.

What SSH Keys Are

An SSH key pair consists of two mathematically linked files: a private key and a public key. The private key is a long cryptographic value stored on the user’s local machine. It must remain private at all times. The public key is derived from the private key and can be shared freely, copied to servers, and treated as non-sensitive. Anyone who has the public key cannot derive the private key from it, because the mathematical relationship between them works only in one direction.

SSH (Secure Shell) is a network protocol for encrypted remote access and file transfer. It was designed to replace Telnet and rsh, which transmitted credentials in plaintext. The SSH protocol supports two authentication methods: password authentication, where the user sends a password that the server verifies, and public key authentication, where the authentication is a cryptographic proof of private key possession. SSH keys are the material used for the second method.

The files themselves are plain text. A typical private key file starts with the line BEGIN OPENSSH PRIVATE KEY or BEGIN RSA PRIVATE KEY and contains a block of base64-encoded data. The corresponding public key file contains a short one-line string with the algorithm identifier, the key data, and an optional comment. The public key is what gets added to servers. The private key never moves.

How SSH Key Authentication Works: The Protocol Sequence

The authentication mechanism is elegant and its security properties follow directly from the mechanism, not from any external trust authority.

When a user initiates an SSH connection, the client sends an authentication request to the server that identifies which public key it wants to use. The server looks in its authorized_keys file, which contains a list of public keys permitted to log in. If the presented key is in the file, the server generates a random challenge value, encrypts it using the public key, and sends the encrypted challenge to the client.

The client can only decrypt this challenge if it possesses the matching private key. It decrypts the challenge, combines the decrypted value with the session identifier in a specific way defined by the SSH protocol, and sends back a hash of the result. The server computes the same hash using its session identifier and the decrypted value it knows (it generated the challenge). If the hashes match, the authentication succeeds.

The private key is never transmitted. The server never sees it. The authentication proves key possession through a challenge-response exchange where only the correct private key can produce the correct response. An attacker who intercepts the challenge cannot authenticate, because decrypting the challenge requires the private key they do not have.

This mechanism is why SSH key authentication is resistant to the attacks that commonly compromise passwords. Phishing cannot steal an SSH private key because there is nothing to enter in a fake login page. Brute-force attacks have no password to guess. Credential stuffing is impossible because there are no reusable credentials. The authentication is mathematically bound to both the specific private key and the specific session, so a captured authentication exchange cannot be replayed.

SSH Key Types: Which Algorithm to Use

SSH key pairs are generated using an underlying asymmetric algorithm. The choice of algorithm determines the key’s security properties, size, and performance. There are four algorithms in widespread use, and the right choice among them has changed as older algorithms have been weakened or deprecated.

Ed25519 is the current recommended choice for new SSH key pairs. It produces small keys (the public key is only about 70 characters), generates and signs faster than RSA at any equivalent security level, and uses a well-scrutinized curve that does not depend on NIST-selected curve parameters. Any server running a version of OpenSSH from 2014 or later (which covers virtually all currently maintained systems) supports Ed25519.

RSA remains appropriate when connecting to older systems that do not support Ed25519, or when an organization requires RSA for policy reasons. If using RSA, 4096 bits is the correct choice. RSA-2048 provides adequate security today but the longer key provides more margin against future attacks at a modest performance cost.

Generating an SSH Key Pair

Key generation creates both files at once. The command is the same on Linux, macOS, and Windows (via OpenSSH on Windows 10 and later or via Git Bash). The private key is saved to a file and the public key is saved to the same filename with a .pub extension.

The passphrase is a second layer of protection for the private key file. If someone gains access to your computer and copies the private key file, they cannot use it without also knowing the passphrase. For keys used in automated scripts and CI/CD pipelines where a human cannot enter a passphrase at each use, keys are typically generated without a passphrase, but those keys must be stored with more care and should have restricted permissions.

Deploying SSH Keys to Servers

Authentication requires the server to have the public key in its authorized list. The server checks the file ~/.ssh/authorized_keys in the home directory of the user account being accessed. Each line in this file is one authorized public key. The file can contain multiple keys, allowing multiple clients to authenticate to the same account.

After adding your public key to a server, test the connection before disabling password authentication. If the key authentication fails due to a permissions problem or wrong key, you will still have password access to fix it. Only disable password authentication once you have confirmed key authentication works correctly.

Disabling Password Authentication After Key Setup

SSH key authentication is significantly more secure than password authentication, but both can coexist. A server that still accepts passwords can still be compromised via brute-force attacks even if SSH keys are configured. For production servers, disabling password authentication entirely and requiring SSH keys is the correct security posture.

Password authentication is disabled in the SSH server configuration file, typically at /etc/ssh/sshd_config on Linux servers. The setting is PasswordAuthentication. Changing it to no means only clients presenting a valid key from the authorized_keys file can connect.

Do not disable password authentication until you have tested that key authentication works from the client that will use this server. If you lock yourself out, recovery typically requires console access, a rescue disk, or cloud provider recovery options. Keep a root or admin session open in a separate terminal while making this change and test login from another terminal before closing the open session.

How SSH Keys Compare to SSL Certificates

Since CompareCheapSSL’s primary focus is SSL certificates, it is worth being precise about how SSH keys and SSL certificates relate to each other. They share the same cryptographic foundation but differ in important ways.

The key practical difference is the trust model. SSL certificate trust is delegated to Certificate Authorities whose root certificates are in browser trust stores. A new SSL certificate from any trusted CA is automatically trusted by every browser without any server-side configuration. SSH key trust is explicit: a server only accepts connections from private keys whose corresponding public keys are in its authorized_keys file. Adding a new key requires access to the server to add the public key.

This difference makes SSH key management a distinct operational challenge from SSL certificate management. You cannot add a new user’s SSH access to a server without modifying the server’s configuration. With SSL certificates, replacing or adding a certificate does not require changing any client configuration.

SSH Key Management at Scale

A single developer with one key and one server has no key management problem. An organization with dozens of developers, hundreds of servers, and automated deployment pipelines has a significant one. SSH keys proliferate easily: developers generate new keys on new machines, old keys from departed employees remain in authorized_keys files on servers they were granted access to, CI/CD systems have their own keys, and service accounts accumulate access over time.

Unlike SSL certificates, which have mandatory expiry and are tracked by Certificate Transparency logs, SSH keys have no built-in expiry and no audit log. An SSH public key added to a server years ago by an employee who has since left the organization remains valid unless someone explicitly removes it. There is no CA system keeping track of which keys exist, no automatic notification when a key should be revoked, and no centralized inventory of which keys have access to which systems.

For organizations managing more than a handful of servers, several approaches address this:

• SSH Certificate Authorities: OpenSSH supports certificate-based authentication where the CA (an internal SSH CA) signs SSH public keys rather than requiring each public key to be individually added to authorized_keys. Signed SSH certificates can be issued with an expiry date, making them analogous to SSL certificates in their lifecycle management.
• Bastion hosts: Route all SSH access through a single jump server or bastion host. All user public keys are managed on the bastion, which then connects to internal servers. This centralizes key management to one location.
• Identity-aware access proxies: Systems like Teleport, HashiCorp Boundary, and Cloudflare Access replace direct SSH access with short-lived certificates issued at login time. Users authenticate through the proxy using corporate identity (SSO, MFA), and the proxy issues a temporary SSH certificate valid for the duration of the session. No persistent private keys are deployed.
• Regular key audits: Periodically check authorized_keys files on all servers against a current employee list and revoke keys belonging to departed employees or accounts that no longer require access.

Security Best Practices for SSH Keys

The security of SSH key authentication depends on how well private keys are protected. The authentication mechanism itself is strong, but its guarantees collapse if the private key is compromised.

Protect the private key file

The private key file should have permissions set to 600 (readable only by the owner, not by any other user or the system). On Linux and Mac this is enforced by the SSH client, which refuses to use a private key file with excessive permissions. On shared machines or systems with multiple users, the private key file should be in a home directory that other users cannot access.

For high-value access, store the private key in a hardware security key such as a YubiKey or similar FIDO2 device. The private key is generated on the hardware device and cannot be extracted from it. Authentication requires the physical device to be present. This completely eliminates the risk of private key theft via malware or filesystem access.

Use passphrases for interactive keys

Any SSH key used for interactive human login should be protected with a passphrase. The passphrase encrypts the private key file, meaning the file is useless to an attacker who steals it without also knowing the passphrase. Use ssh-agent to cache the decrypted key in memory for a session so the passphrase need only be entered once per login session rather than on every SSH connection.

Use separate keys for different purposes

Generating a single key pair and using it for every server, every service, and every environment is convenient but creates a single point of failure. If that key is compromised, every system that trusts it is accessible. Better practice is to use different key pairs for different environments or access levels: one key for production servers, a different key for development environments, another for automated deployment, and so on. A compromise of one key has limited blast radius.

Disable root login over SSH

The SSH server configuration option PermitRootLogin should be set to no on production servers. Even with SSH key authentication, allowing direct root login over SSH is unnecessary and dangerous. Administrators should log in as a regular user and escalate privileges via sudo when needed. This creates an audit trail of administrative actions and limits the damage of a key compromise to regular user access rather than immediate root access.

Frequently Asked Questions

What is an SSH key and what is it used for?

An SSH key is a cryptographic key pair consisting of a private key stored on the user’s local machine and a public key placed on any server the user wants to access. SSH keys are used for passwordless authentication to remote servers over the SSH (Secure Shell) protocol. They are widely used by developers and system administrators for logging into Linux servers, by automated deployment systems for pushing code without manual password entry, and by cloud platforms like AWS, Azure, and Google Cloud for server access management.

How is an SSH key different from a password?

A password is a shared secret: the user knows it and the server stores a hash of it. Anyone who discovers the password can use it from anywhere. An SSH key is an asymmetric key pair: the private key never leaves the user’s machine and is never transmitted to the server. The server stores only the public key. Authentication is a cryptographic proof that the user holds the private key, performed via a challenge-response exchange. SSH key authentication is resistant to brute-force attacks (there is no password to guess), phishing (there is nothing to enter into a fake login page), and credential stuffing (the key is not reusable across different sessions or servers).

Which SSH key type should I use?

Ed25519 is the recommended choice for new SSH key pairs on any modern system. It is faster, produces smaller keys, has a higher security margin than equivalent RSA sizes, and does not depend on NIST curve parameters. Any system running OpenSSH 6.5 or later (released in 2014) supports Ed25519. Use RSA with 4096 bits only when connecting to legacy systems that do not support Ed25519. Do not use DSA, which has a fixed 1024-bit key size that is no longer considered secure, and avoid ECDSA unless there is a specific requirement for it.

What is the difference between a public key and a private key in SSH?

The private key is the secret half of the pair that must remain on the user’s machine and never be shared. It is used to prove identity during authentication by computing a response to the server’s challenge that only the corresponding private key can produce. The public key is mathematically derived from the private key and can be distributed freely. It is placed on servers to authorize access. Anyone who has your public key cannot use it to impersonate you, because producing a valid authentication response requires the private key. The public key only serves to verify responses produced by the private key.

Can SSH keys expire?

Standard SSH keys generated with ssh-keygen do not have an expiry date. Once placed in a server’s authorized_keys file, they remain valid indefinitely unless explicitly removed. This is one of the key management challenges with SSH keys at scale. OpenSSH does support SSH certificates (different from SSL certificates) where the SSH CA can issue a signed version of an SSH public key with an expiry date. SSH certificates combine the cryptographic strength of key authentication with lifecycle management more similar to SSL certificates, including configurable validity periods and centralized revocation.

What should I do if my SSH private key is compromised?

Remove the corresponding public key from the authorized_keys file on every server it was placed on immediately. This is the equivalent of revoking the key. A compromised private key cannot be un-compromised, and there is no CA to notify. Audit all servers the key had access to for unauthorized activity. Generate a new key pair and distribute the new public key to the servers that need it. On cloud platforms, immediately update any stored public key references to the new key. If the compromised key was used in automation or CI/CD, rotate all affected credentials and review what systems the automation had access to.