Create and manage SSH keys

SSH key authentication is safer than a password and makes it possible to automate connections. It is the prerequisite for everything that follows in the SSH path: without a configured key, no password-free login, no reliable Ansible, no CI/CD pipeline.

It is a direct RHCSA objective (Manage security domain, "Configure key-based authentication for SSH") and LFCS objective (Networking domain, "Configure the OpenSSH server and client").

What you will learn

• Generate an Ed25519 key pair (or RSA 4096) with a passphrase
• Deploy the public key to a server with ssh-copy-id
• Manage authorized_keys by hand when needed
• Use ssh-agent to remember the passphrase for the session
• Fix the permissions of ~/.ssh/ that silently block authentication
• Work with several keys for several servers or roles

In which context?

Situation	Technique
Log in to a server without a password	ssh-keygen + ssh-copy-id
Run Ansible without being interrupted	key without passphrase, or ssh-agent
Reach GitHub / GitLab over SSH	dedicated key + ~/.ssh/config
RHCSA exam, "configure key-based auth" task	ssh-keygen + authorized_keys
Client without ssh-copy-id (Windows OpenSSH)	manual copy of the public key

Swipe to see more

---

Generate a key pair

ssh-keygen produces two files: the private key, which never leaves your workstation, and the public key in .pub, meant to be copied to the servers. The algorithm is chosen here and cannot be changed afterwards.

Ed25519, recommended

ssh-keygen -t ed25519 -C "bob@workstation"

The command asks two questions. At Enter file, press Enter to keep the default location (~/.ssh/id_ed25519). At Enter passphrase, type a passphrase: it encrypts the private key on disk, so stealing the file is no longer enough to log in. Output measured on Debian 13 (OpenSSH 10.0), the fingerprint being specific to each key:

Generating public/private ed25519 key pair.
Your identification has been saved in /home/bob/.ssh/id_ed25519
Your public key has been saved in /home/bob/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:wzADwtgppDzS9xC3BfogrcBzlncuuUHV7l0+w0Y1n+I bob@workstation

Ed25519 vs RSA

Ed25519 has existed since OpenSSH 6.5 (2014) and it has been the default type of ssh-keygen since OpenSSH 9.5 (2023): on Debian 13 as on AlmaLinux 10, ssh-keygen without -t already produces an Ed25519 key (measured). Shorter key, faster, as safe as RSA 4096. Only use RSA 4096 with very old systems that do not support it.

RSA 4096, maximum compatibility

RSA remains useful with old equipment that does not know Ed25519: the key is slower to generate and heavier to verify, but it is accepted everywhere.

ssh-keygen -t rsa -b 4096 -C "bob@workstation"

Named key for a specific use

The -f option chooses the file name: one key per use limits the damage if one of them leaks, and lets you revoke it without touching the others. The -C comment reminds what the key is for in authorized_keys.

# Key dedicated to the backup server
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup@workstation"

# Key for GitHub
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_github -C "bob@github"

---

Deploy the public key to a server

Deploying a key means adding its public content to the ~/.ssh/authorized_keys file of the target account. The permissions of this file and of its directory matter as much as its content: too open, and the SSH server refuses the key without telling the client.

With ssh-copy-id (recommended method)

ssh-copy-id bob@192.168.1.10

ssh-copy-id logs in with the password, creates ~/.ssh/authorized_keys on the server if needed, and adds your public key to it.

With a non-standard port or a specific key:

ssh-copy-id -p 2222 bob@192.168.1.10
ssh-copy-id -i ~/.ssh/id_ed25519_backup.pub bob@backup.example.com

Check that it works:

ssh bob@192.168.1.10
# must log in without asking for a password (or with the key's passphrase)

By hand (RHCSA, without ssh-copy-id)

ssh-copy-id ships with the OpenSSH client, in openssh-client on Debian and openssh-clients on RHEL (measured on Debian 13 and AlmaLinux 10). The manual method is still worth knowing: a client without ssh-copy-id, such as the OpenSSH client of Windows, or a server where password login is already closed, forces you to write authorized_keys yourself:

1. Print the public key on the client machine

   cat ~/.ssh/id_ed25519.pub

   Copy the whole line (it starts with ssh-ed25519).

2. On the remote server, prepare authorized_keys

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   echo "ssh-ed25519 AAAA... bob@workstation" >> ~/.ssh/authorized_keys
   chmod 600 ~/.ssh/authorized_keys

3. Check the connection

   ssh bob@192.168.1.10

Mind the permissions

Set chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys: it is the right target, with no margin for error, and it is what an audit expects.

Still, know what really triggers a refusal, because the rule "anything other than 600 is rejected" is false and would send you looking in the wrong place. Eleven real connections measured on AlmaLinux 10 with OpenSSH 9.9p1:

authorized_keys mode	Connection
600, 644, 640	accepted
660, 664, 606, 666	refused

Swipe to see more

What decides is the write permission for the group or for others, never readability. StrictModes refuses that a third party could modify the file, which would amount to letting them add their own key. The same rule applies to ~/.ssh: measured on AlmaLinux 10, 700, 750 and 755 pass, 770, 775 and 777 are refused.

Debian changes this rule. Its OpenSSH tolerates writing by the group when that group is the user's private group and contains only them: measured on Debian 13, ~/.ssh in 770 or 775 passes, only 777 is refused. Do not rely on this tolerance, it disappears on RHEL.

The check also goes one level up from ~/.ssh: a home directory in 770 is enough to make the connection fail, while ~/.ssh and authorized_keys are perfect. The server says so, provided you read its log:

Authentication refused: bad ownership or modes for directory /home/bloc25

And if the file belongs to root, the message is quite different, which points to a chown rather than a chmod:

Could not open user 'bloc25' authorized keys '/home/bloc25/.ssh/authorized_keys': Permission denied

---

Required permissions of ~/.ssh/

It is the first thing to check if key authentication fails:

# SSH directory
chmod 700 ~/.ssh

# Private key: readable by the owner only
chmod 600 ~/.ssh/id_ed25519

# Public key: can be read by everyone
chmod 644 ~/.ssh/id_ed25519.pub

# Authorised keys file: critical
chmod 600 ~/.ssh/authorized_keys

# Client configuration file
chmod 600 ~/.ssh/config

# Known hosts
chmod 644 ~/.ssh/known_hosts

Quick check:

ls -la ~/.ssh/

Expected result:

drwx------ 2 bob bob  4096 Apr  9 10:00 .
-rw------- 1 bob bob   411 Apr  9 10:00 id_ed25519
-rw-r--r-- 1 bob bob    97 Apr  9 10:00 id_ed25519.pub
-rw------- 1 bob bob   582 Apr  9 10:00 authorized_keys
-rw------- 1 bob bob   180 Apr  9 10:00 config

---

ssh-agent: remember the passphrase for the session

If your key is protected by a passphrase, SSH asks for it at every connection. ssh-agent keeps the unlocked key for the whole session.

# Start the agent (if the desktop has not already started it)
eval "$(ssh-agent -s)"

# Add the key: asks for the passphrase only once
ssh-add ~/.ssh/id_ed25519

# Check the loaded keys
ssh-add -l

The output of ssh-add -l gives the key's size, its fingerprint, its comment and its type. Measured on Debian 13:

256 SHA256:wzADwtgppDzS9xC3BfogrcBzlncuuUHV7l0+w0Y1n+I bob@workstation (ED25519)

ssh-agent on desktop systems

On most distributions with GNOME or KDE, an SSH agent starts automatically when you log in. The ssh-add -l command tells you whether keys are already loaded.

Limited lifetime

A key loaded in the agent can be used by any process of your session. The -t option bounds this exposure: after the delay, the agent forgets the key and the passphrase will be asked again.

# Key remembered for 4 hours
ssh-add -t 4h ~/.ssh/id_ed25519

---

Manage several keys

When you use several keys (production servers, backup servers, GitHub, GitLab), declare them in ~/.ssh/config:

# GitHub
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

# Backup servers
Host backup.example.com
    User backupuser
    IdentityFile ~/.ssh/id_ed25519_backup

# Production servers (every IP of the subnet)
Host 10.0.1.*
    User admin
    IdentityFile ~/.ssh/id_ed25519_prod

Without this configuration, SSH tries the default keys (id_ed25519, id_rsa...) in order. With several keys, the explicit declaration avoids "Too many authentication failures" errors.

---

Turn off password authentication (server side)

Once the keys are deployed, turn off password logins to reduce the attack surface. The trap is where to write it: sshd_config starts with Include /etc/ssh/sshd_config.d/*.conf, and the first value read wins. A file of that directory saying PasswordAuthentication yes cancels the line added further down in sshd_config: measured on Debian 13 and AlmaLinux 10 with such a file, sshd -T still prints yes. The case is not exotic: the AlmaLinux 10 image already ships a 25-permitrootlogin.conf that sets PermitRootLogin yes. So write the rule in a file with a low number, read first:

# On the server
echo 'PasswordAuthentication no' | sudo tee /etc/ssh/sshd_config.d/10-hardening.conf
sudo sshd -t                                        # syntax: no output if all is well
sudo sshd -T | grep -i '^passwordauthentication'    # effective value: no

# Reload the service
sudo systemctl reload ssh         # Debian/Ubuntu
sudo systemctl reload sshd        # RHEL/Fedora

Before turning off passwords

Check that your key works from another session before closing the current one. If you lose access, you will have to reach the server through the console (KVM, iLO, iDRAC...).

---

Troubleshooting

Symptom	Likely cause	Action
Permission denied (publickey)	Wrong ~/.ssh/ permissions	Fix with chmod 700 ~/.ssh && chmod 600 authorized_keys
Permission denied (publickey)	Public key missing from authorized_keys	Check with cat ~/.ssh/authorized_keys on the server
SSH still asks for the password	PasswordAuthentication yes read first in sshd_config.d/	sudo sshd -T | grep -i passwordauthentication, then a 10-*.conf drop-in
Too many authentication failures	Too many keys tried	Add IdentitiesOnly yes in ~/.ssh/config
ssh-add -l: "Could not open a connection to your authentication agent"	ssh-agent not started	eval "$(ssh-agent -s)"
Key accepted in the lab but refused on RHEL	Wrong SELinux context on ~/.ssh/	restorecon -Rv ~/.ssh

Swipe to see more

---

Put it into practice

Setting up key access for your own account is one thing; doing it properly for a service user is another. On a VM, this lab makes you generate an Ed25519 pair, deploy the public key in authorized_keys with the right permissions, then harden that account's connection.

Guided lab Practice

Learn how to do it

Set up hardened key-based SSH access for a service user

$ dsoxlab run l4-ssh-key-auth-harden

Environment: VM·Duration: ~20 min

How it is checked: the state of the system is checked after a reboot, not the command you typed.

First time? What DSOXLab is and how to install it

DSOXLab is the command line that prepares a disposable environment (an isolated shell or a VM), runs the lab scenario, then checks the real state of the system and computes a score. Nothing is installed or broken on your workstation.

It needs Python 3.11 or later, uv or pipx, and git. The installation guide details these prerequisites; on Windows, or on a Mac without Python, use the appliance instead.

This lab starts virtual machines: it also needs ansible-playbook, a hypervisor (KVM or Incus), Terraform and hardware virtualization (/dev/kvm), which inside a VirtualBox VM means nested virtualization. The first time, dsoxlab start l4-ssh-key-auth-harden checks all of it before creating the machines. Prepare your machine for vm labs.

Install the CLI and add the catalogue, once:

uv tool install dsoxlab   # or: pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Before you run the lab, check:

• DSOXLab installed
• catalogue available
• compatible environment (isolated shell or VM)

To check, nothing is probed from this page: run dsoxlab doctor. Read the diagnosis

Run this lab, then validate your work:

dsoxlab run l4-ssh-key-auth-harden
dsoxlab check l4-ssh-key-auth-harden

See every lab: dsoxlab list-labs. Track your progress: dsoxlab progress. The full dsoxlab guide covers scoring and the pitfalls.

Key points

• Ed25519 is the recommended choice in 2026: compact, fast, safe
• The ~/.ssh/ permissions are not negotiable: 700 on the directory, 600 on authorized_keys and private keys
• ssh-copy-id is the quick method; the manual copy into authorized_keys is for when the tool is missing, for example from Windows
• PasswordAuthentication no goes in a drop-in read first, and is checked with sshd -T
• ssh-agent removes the repeated passphrase typing without sacrificing security
• On RHEL, think of restorecon if SELinux is active and blocks key authentication

Knowledge check

Check that the essentials of this guide stuck. The questions cover only what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →