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
- Kernel6.12.0-55.9.1.el10_0
- dnf4.20.0
- Flatpak1.16.0
- TimeAbout 15 min
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 | Practice node (graded) - spare /dev/sda | 2 Core | 4 GB | 50 GB + 15 GB |
| RHCSA-B01 | 192.168.0.33 | RHEL 10.0 | Practice node 2 - spare /dev/sdb | 2 Core | 4 GB | 50 GB + 15 GB |
This guide includes
Use this when key authentication silently falls back to a password. This matters because two completely different failures produce the identical symptom - one on the server and one on the client, and both are about permissions.
- generating a key pair
- copying it across, and using it
- meeting StrictModes on the server side
- meeting the same symptom from the client side
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