SSH Public Key

Linux hub

An SSH public key is the shareable half of an asymmetric key pair used for SSH authentication. It is placed in ~/.ssh/authorized_keys on the server. The server uses it to verify that the connecting client holds the matching private key, without the private key ever being transmitted.

Understanding SSH Public Keys

What Is an SSH Public Key in Simple Terms

A key pair works like a padlock and key. The public key is the padlock — you can give it to anyone, put it anywhere, and it does not matter if someone sees it. The private key is the actual key — it must never leave your possession.

When you place your public key on a server, you are installing a padlock that only your private key can open. When you SSH in, the server challenges you to prove you have the matching private key — without you ever sending the private key itself.

How It Works

◈ DIAGRAM

+--------------------+          +--------------------+
| authorized_keys    |          | Your laptop        |
| on server          |          |                    |
|                    |          | Private key:       |
| ssh-ed25519 AAAA...|          | ~/.ssh/id_ed25519  |
| rahul@devops.in    |          | (never shared)     |
+--------------------+          +--------------------+
         |                               |
         | Server sends challenge        |
         | (random data encrypted        |
         |  with your public key)        |
         +-------------------------------+
                       |
         Client decrypts with private key
         Sends proof back to server
         Server verifies: access granted

Public key format:

◈ DIAGRAM

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... rahul@devops.in
|           |                             |
|           base64-encoded key material   comment (optional)
key type

Practical Commands

Bash

## Generate an Ed25519 key pair (preferred over RSA in 2024)
ssh-keygen -t ed25519 -C "rahul@devops.in"
## Creates:
## ~/.ssh/id_ed25519      <- private key (chmod 600)
## ~/.ssh/id_ed25519.pub  <- public key (safe to share)
 
## View your public key
cat ~/.ssh/id_ed25519.pub
 
## Copy public key to server (automated)
ssh-copy-id -i ~/.ssh/id_ed25519.pub rahul@10.0.1.50
## This appends to ~/.ssh/authorized_keys on the server
 
## Or manually append to authorized_keys
cat ~/.ssh/id_ed25519.pub | ssh rahul@10.0.1.50 'cat >> ~/.ssh/authorized_keys'
 
## View authorized keys on server
cat ~/.ssh/authorized_keys
 
## Multiple public keys are allowed -- one per line
## Each line = one authorized client
 
## Restrict what a key can do (in authorized_keys)
## from= restricts which IPs can use this key
## command= forces a specific command regardless of what client requests
cat ~/.ssh/authorized_keys
## from="10.0.0.0/8" ssh-ed25519 AAAA... deploy-automation
## command="/opt/scripts/backup.sh" ssh-ed25519 AAAA... backup-runner
 
## Check key fingerprint
ssh-keygen -l -f ~/.ssh/id_ed25519.pub
## 256 SHA256:abc123... rahul@devops.in (ED25519)

Troubleshooting

Symptom	Command	What to Check
Key not accepted	`ls -la ~/.ssh/authorized_keys`	File must be 600, dir must be 700
Wrong key used	`ssh -i ~/.ssh/specific_key user@host`	Specify key explicitly
Key not found	`ssh-add -l`	Key not loaded in ssh-agent

Remember
The ~/.ssh/ directory must have chmod 700 and authorized_keys must have chmod 600. SSH will silently refuse to use keys with permissions that are too open — this is a deliberate security check.

Security
Rotate SSH keys when team members leave, when a laptop is lost, or at least annually. Remove old public keys from authorized_keys immediately when access should be revoked. A key in authorized_keys grants access as long as it is there, regardless of whether the user still works at the company.

Frequently Asked Questions

Why is it safe to email or paste an SSH public key somewhere, unlike the private key?

The public key is mathematically derived from the private key but the relationship is one-way — you cannot feasibly reverse an SSH public key to recover the private key it came from, given current cryptography (RSA at typical key sizes, or Ed25519). Its only job is letting a server verify a signature produced by the matching private key, so distributing it widely (GitHub profiles, authorized_keys files, CI secrets) carries no risk in itself.

What's a common authorized_keys mistake that silently breaks or over-grants SSH access?

Wrong file permissions on ~/.ssh or ~/.ssh/authorized_keys (they must not be group- or world-writable) cause sshd to silently reject the key with no useful error beyond 'permission denied,' which is a frequent source of confusing troubleshooting. On the access-control side, appending old keys to authorized_keys and never removing them for departed employees or rotated CI credentials means access outlives its intended lifetime — authorized_keys needs the same offboarding discipline as any other credential store.