Enforce Key‑Only SSH Access

Guide to configure OpenSSH to accept only public‑key authentication for a non‑root account, disabling password and root login, with verification and rollback steps.

Desired outcome

The SSH daemon accepts authentication only via a public‑key for a specific non‑root account. Password login and direct root login are refused, reducing exposure to brute‑force and credential‑stuffing attacks.

Prerequisites

An existing working SSH session or console access to the target server (you must keep this open until the new configuration is verified).
sudo or root privileges on the server.
OpenSSH client tools on your workstation (ssh-keygen, ssh-copy-id or manual copy).
A second access path (e.g., IPMI, iLO, cloud console) in case you lock yourself out.

Procedure

Generate a key pair on the client (run in your local terminal):
```
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_example
```
This creates a modern Ed25519 key with 100 KDF rounds. You will be prompted for a passphrase; remember it or use an agent.
Install the public key on the server (replace user and host with your account and server address):
```
ssh-copy-id -i ~/.ssh/id_ed25519_example.pub user@host
```
If ssh-copy-id is unavailable, manually append the content of ~/.ssh/id_ed25519_example.pub to ~user/.ssh/authorized_keys and set permissions:
```
chmod 700 ~user/.ssh
chmod 600 ~user/.ssh/authorized_keys
chown -R user:user ~user/.ssh
```
Verify key‑based login works (open a new terminal; keep the original session open):
```
ssh -i ~/.ssh/id_ed25519_example user@host
```
You should be prompted only for the key passphrase, not for a password.
Edit the SSH daemon configuration. Create a drop‑in file to avoid editing the main file directly (requires root):
```
sudo tee /etc/ssh/sshd_config.d/key-only.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
EOF
```
Validate the syntax:
```
sudo sshd -t
```
A silent exit means the configuration parses correctly.
Reload the SSH daemon (existing sessions stay alive):
```
sudo systemctl reload sshd
```
On systems without systemctl, use the appropriate init command (e.g., service ssh reload).

Expected checks

From a new terminal, run:
```
ssh -v user@host 2>&1 | grep 'Authentications that can continue'
```
You should see publickey as the only offered method.
Attempt a password login to confirm it is rejected:
```
ssh -o PreferredAuthentications=password user@host
```
The connection should terminate with Permission denied (publickey).

Check the effective daemon settings:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|pubkeyauthentication'

Expected output:

passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Inspect the authentication log for a successful public‑key event:
```
sudo journalctl -u sshd | grep 'Accepted publickey'
```

Recovery / Rollback

If you cannot log in after the reload, use your console or out‑of‑band access to:

Remove or rename the drop‑in file:

sudo mv /etc/ssh/sshd_config.d/key-only.conf /etc/ssh/sshd_config.d/key-only.conf.disabled

Reload SSH again:
```
sudo systemctl reload sshd
```
Verify that password login works again, then re‑examine the configuration for errors (e.g., typos, missing directives).

Limitations and practical verification

Disabling PasswordAuthentication does not affect other keyboard‑interactive methods on very old OpenSSH releases; ensure KbdInteractiveAuthentication (or ChallengeResponseAuthentication on OpenSSH < 8.7) is also set to no.
Cloud images may re‑apply settings via cloud‑init or vendor drop‑ins after a reboot. After applying changes, reboot the host and repeat the checks to confirm persistence.
Always keep at least one authenticated session open until you have verified the new configuration with a fresh login attempt.

Enforce Key‑Only SSH Access on OpenSSH Server