Linux SSH Keys

Why SSH Keys Matter

SSH keys are one of the most common ways to authenticate securely to Linux servers, Git hosts, and automation systems. Compared to passwords, they are more resistant to guessing attacks and much easier to automate safely.

For DevOps work, SSH keys are everywhere: server access, Git operations, CI deployments, bastion hosts, and remote automation.

How SSH Key Authentication Works

SSH key authentication is based on a public/private key pair.

• the private key stays on your machine and must be protected
• the public key can be shared with servers or services

When you connect, the server checks whether your public key is trusted and then proves that your client holds the matching private key.

The private key should never be copied casually between machines or committed to source control.

Generating a Key with ssh-keygen

The recommended modern key type for most users is ed25519.

ssh-keygen -t ed25519 -C "devops@example.com"

You will normally be asked:

• where to save the key
• whether to set a passphrase

A passphrase protects the private key at rest. If someone copies your key file, the passphrase adds an extra barrier.

Example custom filename:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work key"

Tip: Use separate keys for different environments when you need better isolation, such as work, personal, and production access.

Installing the Public Key on a Server

The server stores trusted public keys in:

~/.ssh/authorized_keys

A convenient way to copy your key is:

ssh-copy-id devops@server.example.com

That appends your public key to the remote authorized_keys file.

You can also do it manually by copying the contents of your .pub file.

cat ~/.ssh/id_ed25519.pub

Then paste that public key into ~/.ssh/authorized_keys on the server.

Correct File Permissions

SSH is strict about permissions because weak permissions can expose keys.

Typical secure settings are:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

If permissions are too open, SSH may refuse to use the files.

Note: Permission problems are a very common reason key authentication fails even when the key content itself is correct.

Using ~/.ssh/config

The SSH client config file lets you define shortcuts and per-host settings.

Example:

Host prod-web
    HostName server.example.com
    User devops
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_work

After this, you can connect with:

ssh prod-web

Useful options in ~/.ssh/config include:

• Host for the alias
• HostName for the real server name or IP
• User for the login account
• Port for non-default SSH ports
• IdentityFile for selecting a specific key

This keeps complex SSH commands out of your memory and scripts.

Working with ssh-agent and ssh-add

If your private key has a passphrase, entering it every time can be inconvenient. ssh-agent stores unlocked keys in memory for the session.

Start or use the agent, then add a key:

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

Now SSH can use the unlocked key without prompting for the passphrase on every connection.

Agent Forwarding

Agent forwarding lets a remote host use your local SSH agent to authenticate to another host without copying your private key to the first server.

Example:

ssh -A bastion.example.com

This is useful in jump-host workflows, but it should be enabled carefully. If the intermediate host is compromised, agent forwarding can increase risk.

Only use it where you trust the systems involved.

A Practical Workflow

A typical first-time setup looks like this:

ssh-keygen -t ed25519 -C "devops@example.com"
ssh-copy-id devops@server.example.com
ssh devops@server.example.com

If the login fails, check:

• whether the correct public key is in authorized_keys
• whether ~/.ssh and key files have safe permissions
• whether the correct private key is being used
• whether the server allows key authentication

For noisy debugging, SSH can show details:

ssh -v devops@server.example.com

What You Should Remember

SSH keys work by matching a local private key with a trusted public key on the server. Generate modern keys with ssh-keygen, protect them with a passphrase, use authorized_keys correctly, and simplify repeated connections with ~/.ssh/config and ssh-agent.

Once this workflow feels natural, remote Linux access becomes faster and more secure.

Test Your Understanding