Move to keys and close the door behind you

short · 30 min · Objective 3.3

Before you start — what this lab needs

A disposable virtual machine running sshd, reached from a second machine. Keep one session open throughout, so a mistake never leaves you locked out:

# on the server
dnf install -y openssh-server && systemctl enable --now sshd

Task

Set up key-based SSH, disable password authentication, and do it in the order that does not lock you out. Then reproduce the permission error that produces the unhelpful "Permission denied" and find its real cause in the server log.

Steps

From the client, generate a key pair with ssh-keygen -t ed25519 and copy the public half with ssh-copy-id user@server.
Confirm key login works in a NEW session while keeping your current one open. Only now proceed.
Break the permissions deliberately: chmod 777 ~/.ssh on the server and attempt a key login. It fails with "Permission denied" on the client.
Read the real reason on the server: journalctl -u sshd reports bad ownership or modes. Fix with chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys and confirm login works.
Validate a config change before applying it: edit sshd_config to set PasswordAuthentication no and PermitRootLogin no, run sshd -t, then systemctl reload sshd rather than restart.
Confirm from the client that password login is now refused and key login still works.
Add AllowUsers naming only yourself, reload, and confirm an unlisted user is refused before authentication even begins.

Verify

sshd -t && echo "config valid"
sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers'
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@server true 2>&1 | grep -qi 'permission denied' && echo "password auth disabled"
ssh -o PreferredAuthentications=publickey user@server true && echo "key auth works"

The last two must both hold: password refused, key accepted. Run sshd -t before every reload -- a syntax error plus a restart plus a closed session is the classic way to need the console.

Notes

The permission error in step 3 is the single most common SSH key failure and the client is told nothing useful about it on purpose. The habit that saves you is the one in step 2: prove a new session works before you close the one you have.