19.3 Configure Key-Based Authentication for SSH

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

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'

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).

# 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)

1. Install and test key login in a second session first.
2. Keep an existing root console or lab console available.
3. Only then set PasswordAuthentication no.
4. Reload sshd; confirm a new SSH session still works with the key.
5. 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

1. Copying the private key into authorized_keys instead of the .pub file.
2. ~/.ssh mode 755/775 or authorized_keys 644 with group write—sshd rejects keys.
3. Wrong ownership (root-owned authorized_keys in a user home).
4. PasswordAuthentication no before keys work—self-lockout.
5. Editing sshd_config with typos and restarting without sshd -t.
6. Forgetting systemctl reload sshd after config changes.
7. Installing keys for user A but testing login as user B.
8. Broken line wrapping in authorized_keys.
9. Firewall blocking 22/tcp while blaming key files.
10. Assuming ssh-keygen alone configures the server—you must install the public key.

Relationship to other sections

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.