Understanding SSH Key Authentication: Public vs. Private Keys Explained

SSH key authentication is the normal way many administrators, developers, CI systems, and deployment tools log in to servers. Your laptop keeps a private key, the server stores the matching public key, and SSH proves you have the private key without sending it across the network.

That last part is the whole point. A password is a secret you type into many places. A private key is a secret that should stay on your machine. If you protect it with a passphrase and store only the public key on servers, you get a login method that is both safer and easier to automate than shared passwords.

The Problem with Passwords

Traditional password-based authentication relies on a shared secret: the password. While strong passwords can provide a decent level of security, they are susceptible to several weaknesses:

Brute-force attacks: Attackers can try countless password combinations until they guess correctly.
Dictionary attacks: Using common words or phrases, attackers can quickly compromise accounts.
Keyloggers: Malicious software can capture keystrokes, revealing passwords.
Phishing: Social engineering tactics can trick users into divulging their credentials.
Human error: Users often choose weak, guessable, or reused passwords, and may accidentally expose them.

SSH key authentication reduces those risks because the private secret is not typed into the remote server. That does not make keys magic. A stolen unencrypted private key can still be abused, and a badly managed authorized_keys file can become a quiet backdoor.

SSH Key Authentication: An Overview

SSH key authentication leverages asymmetric cryptography, a system that uses a pair of mathematically linked keys: a public key and a private key. Unlike symmetric cryptography, where the same key is used for both encryption and decryption, asymmetric cryptography uses one key for encryption and a different, but related, key for decryption.

When you connect with keys, the server checks whether your account trusts the public key being offered. Your client then signs authentication data with the matching private key. The server verifies that signature with the public key. The private key is not uploaded to the server.

The Cryptographic Duo: Public and Private Keys

At the heart of SSH key authentication are these two distinct, yet interconnected, components.

The Private Key

The private key is your secret identity. It is a long, complex string of characters that must be kept absolutely confidential and never shared with anyone. Think of it as the unique key to your digital lockbox.

Security Critical: If your private key is compromised, an attacker could impersonate you and gain unauthorized access to any server where the corresponding public key has been deployed.
Location: Typically stored on your local machine (e.g., ~/.ssh/id_rsa, ~/.ssh/id_ed25519).
Protection: It can be protected by a passphrase. If someone copies the key file, the passphrase is the extra barrier between "file stolen" and "server access stolen."

The Public Key

The public key is the counterpart to your private key. It is derived from your private key but cannot be used to recreate the private key. As its name suggests, the public key is meant to be shared and placed on any server you wish to access.

Shareable: You can safely distribute your public key to anyone or any server without compromising your security.
Location: On the server, public keys are typically stored in the ~/.ssh/authorized_keys file for each user account. Each line in this file represents a trusted public key.
Role: The public key lets the server verify a signature made by the matching private key.

How SSH Key Authentication Works: The Handshake

Let's break down the step-by-step process of how SSH key authentication establishes a secure connection:

Key Pair Generation: First, you generate a public and private key pair on your local machine. The private key stays secret, and the public key is what you'll distribute.
Public Key Deployment: You copy your public key to the remote server you want to access. This key is typically added to the ~/.ssh/authorized_keys file in your user's home directory on the server.
Connection Attempt: When you initiate an SSH connection from your local machine to the remote server, your SSH client indicates that it wants to authenticate using a key.
Server Check: The server checks whether the offered public key is allowed for that user.
Client Proof: Your client signs authentication data with the private key. If the private key has a passphrase, you may be asked to unlock it locally.
Verification: The server verifies the signature using the public key from authorized_keys. If the signature is valid and the account is allowed to log in, authentication succeeds.
Authentication Granted: If the verification is successful, the server grants you access, and a secure SSH session is established.

Crucially, your private key never leaves your local machine during this entire process. Only cryptographic proofs derived from it are exchanged.

Generating an SSH Key Pair

Generating an SSH key pair is a straightforward process using the ssh-keygen command on your local machine (Linux, macOS, or WSL/Git Bash on Windows).

ssh-keygen -t ed25519 -C "[email protected]"

-t ed25519: Specifies the type of key to create. Ed25519 is a modern default for most new OpenSSH keys. RSA is still common, especially around older systems.
-C "[email protected]": Adds a comment to the public key, which helps you identify its purpose or owner.

You'll be prompted for a file to save the key (default is ~/.ssh/id_ed25519) and a passphrase. Always use a strong passphrase to protect your private key.

Generating public/private ed25519 key pair.
Enter file in which to save the key (~/.ssh/id_ed25519):
Created directory '/home/youruser/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/youruser/.ssh/id_ed25519.
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub.
The key fingerprint is: SHA256:...
The key's randomart image is:
+--[ED25519 256]----+
|      .=+          |
|     . o. .        |
|    . + o.         |
|   o = B o.        |
|  . S @ + +        |
|   = + B .         |
|  o * * E          |
| . o o             |
|  . .              |
+----[SHA256]-------+

After generation, you'll have two files in your ~/.ssh directory:

id_ed25519 (your private key)
id_ed25519.pub (your public key)

Make sure your private key file has strict permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Deploying Your Public Key

To use key authentication, your public key must be placed on the remote server you wish to access.

Using `ssh-copy-id` (Recommended)

The ssh-copy-id utility is the simplest and safest way to deploy your public key. It handles creating the ~/.ssh directory and authorized_keys file with correct permissions if they don't exist.

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote_host

Replace user with your username on the remote server and remote_host with the server's IP address or hostname. You will be prompted for your password for the user@remote_host one last time to upload the key.

Manual Deployment

If ssh-copy-id is not available, you can copy the public key manually:

Copy the public key content: Display your public key using cat.
```
cat ~/.ssh/id_ed25519.pub
```
Copy the entire output, which starts with ssh-ed25519 ... and ends with your comment.
SSH into the remote server using password authentication:
```
ssh user@remote_host
```
Enter your password when prompted.

Create ~/.ssh directory and authorized_keys file if they don't exist:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Append your public key to authorized_keys: Paste the public key content you copied earlier into the authorized_keys file.
```
echo "ssh-ed25519 AAAA..." >> ~/.ssh/authorized_keys
```
(Replace ssh-ed25519 AAAA... with your actual public key content)

Connecting with SSH Keys

Once your public key is on the server, you can connect simply by specifying the user and host:

ssh user@remote_host

If you have multiple key pairs or your private key is not in the default location (~/.ssh/id_rsa or ~/.ssh/id_ed25519), you might need to specify it using the -i option:

ssh -i ~/.ssh/my_custom_key user@remote_host

If your private key is protected by a passphrase, you will be prompted to enter it. To avoid entering the passphrase repeatedly during a session, you can use ssh-agent.

Security Benefits of SSH Key Authentication

Reduces password guessing risk: If password login is disabled, attackers cannot brute-force that account through SSH passwords.
Stronger credentials: A properly generated SSH key is not something a human can guess.
No private key upload: Your private key stays local during authentication.
Automation Friendly: Keys allow for scriptable, password-less logins, which is essential for automation tools and CI/CD pipelines.
Passphrase Protection: Adding a passphrase to your private key provides an extra layer of security. Even if your private key file is stolen, it remains unusable without the passphrase.

Managing Your SSH Keys

`ssh-agent`

ssh-agent is a program that runs in the background and holds your decrypted private keys in memory. When you attempt to connect to an SSH server, your SSH client can query ssh-agent for the necessary private key, eliminating the need to type your passphrase repeatedly.

To start ssh-agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

You'll enter your passphrase once when adding the key to the agent.

Key Naming and Organization

For managing multiple keys (e.g., for different organizations, projects, or personal use), consider using meaningful names:

ssh-keygen -t ed25519 -f ~/.ssh/id_work_project -C "work_project_key"
ssh-keygen -t ed25519 -f ~/.ssh/id_personal_github -C "personal_github_key"

You can then specify which key to use with the -i option, or configure your ~/.ssh/config file to automatically select the correct key based on the host.

Example ~/.ssh/config:

Host github.com
    IdentityFile ~/.ssh/id_personal_github
    User git

Host work-server
    Hostname 192.168.1.100
    IdentityFile ~/.ssh/id_work_project
    User devuser

Best Practices and Tips

Never share your private key: This is the golden rule. Your private key is your digital identity.
Use a strong passphrase: Protect your private key with a robust passphrase, similar to a strong password. This makes your key useless even if it falls into the wrong hands.
Rotate when there is a reason: Generate a new key when a device is lost, a contractor leaves, a key was shared by mistake, or an old algorithm no longer fits your policy.
Restrict file permissions: Ensure your private key file has 600 permissions (rw-------) and your ~/.ssh directory has 700 (rwx------).
Disable password authentication carefully: Once key login works from a second terminal, many servers should set PasswordAuthentication no in /etc/ssh/sshd_config. Keep console access available before changing this on remote systems.
Use ssh-agent: For convenience and security, use ssh-agent to manage your keys, especially those with passphrases.

A Simple Mental Model

The public key is the lock you install on the server account. The private key is the credential you keep on your own machine. The passphrase protects that credential if the file is copied. The authorized_keys file is the access list.

Most SSH key problems come from mixing those up: copying the private key to the server, pasting the public key under the wrong user, using the wrong identity file, or leaving permissions too open for OpenSSH to trust them. Name keys by purpose, protect private keys with passphrases, use ssh-agent for convenience, remove old public keys when access should end, and test changes from a second terminal before disabling password login.