Hands-on Lab·Red Hat Certified System Administrator
SSH Key-Based Authentication
One objective, three commands, and two failure modes that produce the identical unhelpful message. Both are demonstrated: a permissive `~/.ssh` on the server, which sshd silently refuses, and a readable private key on the client, which ssh refuses with a wall of asterisks.
Security and SELinux Guide 53 of 67 Intermediate
- OSRHEL 10.0 (Coughlan)
- Kernel6.12.0-55.9.1.el10_0
- dnf4.20.0
- Flatpak1.16.0
- TimeAbout 15 min
- Reviewed23 August 2026
Written against the versions above. sshd's **StrictModes** defaults to `yes` and refuses to use `authorized_keys` if the home directory or `~/.ssh` is writable by anyone but the owner. It logs the reason and tells the client only `Permission denied (publickey)`, so the useful detail is on the server in the journal.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| RHCSA-A01 | 192.168.0.31 | RHEL 10.0 (Coughlan) | Practice node (graded) - spare /dev/sda | 2 Core | 4 GB | 50 GB + 15 GB |
| RHCSA-B01 | 192.168.0.33 | RHEL 10.0 (Coughlan) | Practice node 2 - spare /dev/sdb | 2 Core | 4 GB | 50 GB + 15 GB |
Before you start
- Two machines you can already reach.
- The permission demonstration uses a dedicated
keydemoaccount on the far end, never the account you are logged in with.
-
Generate
-
Copy and use
-
StrictModes on the server
-
And the client side