ExamFinch.com My Study

Study guide

19.3 Configure Key-Based Authentication for SSH

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

19.3 Configure Key-Based Authentication for SSH

Key Takeaways Explain This Topic AI

Generate key pairs with ssh-keygen (commonly Ed25519 or RSA); protect private keys and distribute only the public key.

Install the public key into ~/.ssh/authorized_keys on the target account; directory ~/.ssh must be 700 and authorized_keys (and private keys) 600.

Test with ssh -i KEY user@host and prefer key login before tightening PasswordAuthentication.

Disable password authentication only carefully in sshd_config (PasswordAuthentication no) and reload sshd after key login is proven—avoid locking yourself out.

Client config (~/.ssh/config) and ssh-copy-id speed workflows; end state is successful key auth with correct ownership and modes that sshd will accept.

Last updated: August 2026

19.3 Configure Key-Based Authentication for SSH

Quick Answer: Create a key pair with ssh-keygen . Put the public key in the remote user’s ~/.ssh/authorized_keys . Enforce modes ~/.ssh → 700 , authorized_keys and private keys → 600 (owner must own the files). Log in with ssh -i ~/.ssh/id_ed25519 user@host . Only after key login works should you consider PasswordAuthentication no in sshd_config and systemctl reload sshd .

Why key-based SSH is an EX200 security skill

Earlier objectives cover accessing remote systems with SSH . Under Manage security , you must configure key-based authentication : passwordless (or passphrase-protected key) logins using public-key crypto, correct file permissions, and sometimes hardening sshd so passwords are no longer accepted.

Task language examples:

  • “Configure SSH key-based authentication for user alice from host A to host B.”
  • “Install the provided public key so bob can log in without a password.”
  • “Ensure SSH directory permissions are correct.”

“Disable password authentication for SSH” (only when keys are already working).

Graders check login success with keys , file modes/ownership , and sshd settings when hardening is required.

Key pair concepts

  • Piece Role Secrecy
  • Private key ( id_ed25519 , id_rsa , …) Proves identity on the client Never copy to untrusted hosts; mode 600
  • Public key ( *.pub ) Placed in authorized_keys on the server Can be distributed
  • Passphrase (optional) Encrypts private key at rest on client Not the same as account password

Authentication flow (simplified): server challenges; client signs with private key; server verifies using public key in authorized_keys .

Generate keys with ssh-keygen

On the client (as the user who will initiate SSH): ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C 'alice@workstation'

# or RSA if required:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C 'alice@workstation'

  • Option Purpose
  • t ed25519 / -t rsa Key algorithm
  • b 4096 RSA bit length
  • f path Output path for private key (public gets .pub )
  • N '' Empty passphrase (exam convenience—use only if allowed)
  • C comment Comment field
  • Non-interactive empty passphrase example: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N '' -C 'exam-key'
  • ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Do not overwrite existing keys unless intended ( ssh-keygen prompts). Use a distinct -f path for a second key.

Install the public key on the server

Method A — ssh-copy-id (when password login still works) ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@server.example.com

Creates ~alice/.ssh if needed, appends the public key to authorized_keys , and tends to set reasonable modes.

  • Method B — Manual install (common on exams)
  • On the server , as the target user (or as root fixing that user’s files): sudo mkdir -p /home/alice/.ssh
  • sudo chmod 700 /home/alice/.ssh
  • # append public key line exactly (one line)
  • echo 'ssh-ed25519 AAAA...comment' | sudo tee -a /home/alice/.ssh/authorized_keys
  • sudo chmod 600 /home/alice/.ssh/authorized_keys
  • sudo chown -R alice:alice /home/alice/.ssh

From the client you can also: cat ~/.ssh/id_ed25519.pub | ssh alice@server 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

  • authorized_keys format
  • Each line is one key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... alice@workstation
  • ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... bob@laptop

No broken line wraps. Multiple keys = multiple lines.

Permissions that OpenSSH enforces (critical)

sshd is strict. Wrong modes → key auth silently fails (falls back to password if still enabled).

  • Path Typical required mode Owner
  • ~ home directory Not group/world-writable (often 755 or tighter) user
  • ~/.ssh 700 user
  • ~/.ssh/authorized_keys 600 (or 640 in some setups; prefer 600 ) user
  • Private key on client 600 user
  • Public key 644 is fine user # Server-side fix pattern
  • chmod 700 ~/.ssh
  • chmod 600 ~/.ssh/authorized_keys
  • chown -R "$USER:$USER" ~/.ssh
  • # Client-side private key
  • chmod 600 ~/.ssh/id_ed25519
  • If home is group-writable, modern OpenSSH may refuse key auth. Fix: chmod go-w /home/alice
  • Logging in with a specific key ssh -i ~/.ssh/id_ed25519 alice@server.example.com
  • ssh -v -i ~/.ssh/id_ed25519 alice@server.example.com # debug

Verbose mode shows whether publickey is offered and whether the server accepted it—use when troubleshooting modes.

  • Client config (~/.ssh/config) cat >> ~/.ssh/config <<'EOF'
  • Host labserver
  • HostName server.example.com
  • User alice
  • IdentityFile ~/.ssh/id_ed25519
  • IdentitiesOnly yes
  • EOF
  • chmod 600 ~/.ssh/config
  • ssh labserver

IdentitiesOnly yes prevents offering many default keys that might confuse agent/server limits.

sshd_config: password authentication (careful hardening)

Key files alone do not disable passwords. To require keys: sudo grep -E '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin|ChallengeResponseAuthentication|KbdInteractiveAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/* 2>/dev/null

Typical hardening directives (names may appear in drop-in files under /etc/ssh/sshd_config.d/ ): PubkeyAuthentication yes

PasswordAuthentication no

# Sometimes also:

  • KbdInteractiveAuthentication no
  • Edit safely with a drop-in: sudo tee /etc/ssh/sshd_config.d/99-local-hardening.conf <<'EOF'
  • PasswordAuthentication no
  • PubkeyAuthentication yes
  • EOF
  • Validate and reload: sudo sshd -t
  • sudo systemctl reload sshd
  • # or: sudo systemctl restart sshd
  • Lockout avoidance (exam survival)

Install and test key login in a second session first.

Keep an existing root console or lab console available.

Only then set PasswordAuthentication no .

Reload sshd; confirm a new SSH session still works with the key.

Never close your only working session before the test succeeds.

If you disable passwords without a working authorized key, you may fail the objective and lose remote access.

Root login nuances PermitRootLogin prohibit-password # keys for root, not passwords (common modern default idea)

  • PermitRootLogin no # no root SSH at all
  • PermitRootLogin yes # allow root (often discouraged)

Only change root SSH policy when the task requires it.

SELinux and SSH home contexts

If modes are correct but keys fail after copying from odd paths, restore contexts: restorecon -Rv /home/alice/.ssh

ls -lZ /home/alice/.ssh

Wrong SELinux types on authorized_keys can block access even when DAC modes look fine (deeper SELinux chapters).

Firewall reminder

Key configuration does not open the network path. Ensure ssh service or port 22/tcp is allowed in firewalld if you tightened zones (Sections 17.4 / 19.1). firewall-cmd --list-services

  • # include ssh if remote access is required
  • Verification checklist # Client
  • ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub
  • ssh -i ~/.ssh/id_ed25519 alice@server true && echo key-ok
  • # Server
  • sudo ls -la /home/alice/.ssh
  • sudo stat -c '%a %U %G %n' /home/alice/.ssh /home/alice/.ssh/authorized_keys
  • sudo grep -v '^#' /home/alice/.ssh/authorized_keys | head
  • # If hardened
  • sudo sshd -T | grep -i passwordauthentication
  • sudo systemctl is-active sshd

sshd -T prints effective config—useful when drop-ins override the main file.

  • Exam workflows
  • Workflow A — New Ed25519 key + ssh-copy-id ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ''
  • ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@server
  • ssh -i ~/.ssh/id_ed25519 alice@server

Workflow B — Manual authorized_keys as root on server # public key content available in /root/alice.pub or similar

  • sudo mkdir -p /home/alice/.ssh
  • sudo cp /root/alice.pub /home/alice/.ssh/authorized_keys # if single key file
  • sudo chown -R alice:alice /home/alice/.ssh
  • sudo chmod 700 /home/alice/.ssh
  • sudo chmod 600 /home/alice/.ssh/authorized_keys
  • Workflow C — Permissions repair when keys “mysteriously” fail sudo chmod go-w /home/alice
  • sudo chmod 700 /home/alice/.ssh
  • sudo chmod 600 /home/alice/.ssh/authorized_keys
  • sudo chown -R alice:alice /home/alice/.ssh
  • sudo restorecon -Rv /home/alice/.ssh

Workflow D — Disable password auth after key success ssh -i ~/.ssh/id_ed25519 alice@server true # must work first

  • sudo tee /etc/ssh/sshd_config.d/99-no-pass.conf <<'EOF'
  • PasswordAuthentication no
  • PubkeyAuthentication yes
  • EOF
  • sudo sshd -t && sudo systemctl reload sshd
  • ssh -i ~/.ssh/id_ed25519 alice@server true
  • # password login should now fail
  • Workflow E — Dedicated key file path ssh-keygen -t ed25519 -f ~/.ssh/lab_exam -N ''
  • ssh-copy-id -i ~/.ssh/lab_exam.pub user@host
  • ssh -i ~/.ssh/lab_exam user@host
  • Common traps

Copying the private key into authorized_keys instead of the .pub file.

~/.ssh mode 755/775 or authorized_keys 644 with group write —sshd rejects keys.

Wrong ownership (root-owned authorized_keys in a user home).

PasswordAuthentication no before keys work —self-lockout.

Editing sshd_config with typos and restarting without sshd -t .

Forgetting systemctl reload sshd after config changes.

Installing keys for user A but testing login as user B .

Broken line wrapping in authorized_keys .

Firewall blocking 22/tcp while blaming key files.

Assuming ssh-keygen alone configures the server —you must install the public key.

Relationship to other sections

  • Skill Section
  • Basic SSH access Essential tools (SSH remote access)
  • Firewall allows for ssh 17.4 / 19.1
  • Users and homes 18.x
  • Default create modes 19.2 (umask)—still chmod ssh paths
  • SELinux contexts Later SELinux chapters
  • Section checkpoint

You should generate keys with ssh-keygen , install public keys into authorized_keys , enforce 700 / 600 ownership and modes, prove login with ssh -i , optionally configure client IdentityFile , and only then harden PasswordAuthentication with a validated sshd reload . That is EX200 key-based SSH authentication on RHEL 10.