openSUSE server: sudo, SSH keys and a hardened sshd

An admin user and sudo on openSUSE

openSUSE's default sudo rule asks for the password of the target user, which is root (Defaults targetpw). That works, but it means everyone who administers the box shares the root password. The cleaner setup is the one Fedora uses: members of wheel type their own password.

sudo zypper install sudo-policy-wheel-auth-self   # needs root (root's password this once)
sudo usermod -aG wheel alice
# log out and back in, then:
id                                                # wheel is listed
sudo -k; sudo true                                # now asks for alice's password

The details of users, groups and sudo are in the users, groups and sudo guide.

Key login first

On your laptop, not on the server:

ssh-keygen -t ed25519 -C "alice@laptop"         # accept the path, set a passphrase
ssh-copy-id alice@192.168.1.10                   # asks the account password one last time
ssh alice@192.168.1.10                           # should log in without that password

The SSH key and config helper walks through the same steps and also gives you a short ~/.ssh/config entry, so ssh homeserver is enough.

What ssh-keygen leaves behind, made here with an empty passphrase in a scratch folder (use a passphrase for a real key):

$ ssh-keygen -q -t ed25519 -N '' -C user@laptop -f ./id_ed25519_demo
$ ls -l id_ed25519_demo*
-rw------- 1 user user 399 Sep 28 06:36 id_ed25519_demo
-rw-r--r-- 1 user user  93 Sep 28 06:36 id_ed25519_demo.pub
$ ssh-keygen -lf id_ed25519_demo.pub
256 SHA256:LDEWcTDpj2emLaZoaLEIQDJiwiWahmO7hH4BjZkvpgw user@laptop (ED25519)

The private key is readable by you alone (-rw-------); only the .pub file goes to the server. The fingerprint is what the server shows in its log when you log in.

Harden sshd with a drop-in file

Do not edit the vendor file. Create a drop-in instead (needs root):

sudoedit /etc/ssh/sshd_config.d/10-hardening.conf

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers alice

• PasswordAuthentication no and KbdInteractiveAuthentication no: keys only.
• PermitRootLogin no: log in as yourself and use sudo, so the log shows who did what.
• AllowUsers: only the listed accounts may log in over SSH at all. Add every user who needs SSH, including service users you log in as.

Why 10-: for most options sshd keeps the first value it reads, and it reads drop-ins in name order. A low number beats a later file that says the opposite. All options are in sshd_config(5).

A test with a scratch copy: the main file includes the drop-in first and then says PasswordAuthentication yes. sshd -T prints the settings sshd would really use, and the drop-in wins:

$ cat sshd_config
Include /etc/ssh/10-hardening.conf
HostKey /etc/ssh/hostkey
PasswordAuthentication yes
PidFile none
$ sshd -T -f ./sshd_config | grep -E '^(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication|AllowUsers) '
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers alice

Test without locking yourself out

sudo sshd -t                                     # syntax check; silent means fine
sudo sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitroot'
sudo systemctl reload sshd                       # existing sessions stay open

Keep your current session open. In a second terminal, log in again. Then prove that passwords are really refused:

ssh -o PubkeyAuthentication=no alice@192.168.1.10
# expected: Permission denied (publickey).

Only when both tests pass, close the first session.

Keep port 22 off the internet

Key-only SSH is strong, but a port forward still invites the whole internet to knock. Reach the server from outside through WireGuard instead: the router forwards one UDP port, and SSH stays on the LAN and the tunnel. The Cockpit over WireGuard guide shows the firewalld zones for that setup, and the firewalld basics guide explains zones in general.

Common mistakes

Frequently asked questions