Chapter 10: Secure remote access
Exercise: Harden sshd, safely
Turn off password logins on servera, prove the change with a failed password attempt and a working key login, learn why a drop-in named 99- does not work, and finish by undoing the changes.
Harden sshd, safely
- Write a sshd drop-in and verify it with sshd -T.
- Demonstrate that password logins are refused and key logins still work.
- Explain the first-value-wins rule.
Start the exercise
On workstation, start the exercise. It creates the account ops on servera with a key (~/.ssh/id_ops on workstation) that you will keep using after passwords are switched off.
[student@workstation ~]$ lab start sa-hardeningLater tasks assume that you are logged in to the server they name: ssh student@servera from workstation, then sudo -i for a root shell.
Open the spare session
Open two terminals on workstation, both logged in to servera as root (ssh root@servera). Leave the second one alone: it is your way back in if the change goes wrong. Show the current values of the options you will change.
[student@workstation ~]$ ssh root@servera
[root@servera ~]# sshd -T | grep -E '^(passwordauthentication|x11forwarding|maxauthtries|permitrootlogin) '
maxauthtries 6
permitrootlogin without-password
passwordauthentication yes
x11forwarding yes
[root@servera ~]# ls /etc/ssh/sshd_config.d
50-cloud-init.conf 50-redhat.confTry the wrong file name first
Create /etc/ssh/sshd_config.d/99-hardening.conf with PasswordAuthentication no, X11Forwarding no and MaxAuthTries 3. Check with sshd -T. Which options took effect?
[root@servera ~]# printf 'PasswordAuthentication no\nX11Forwarding no\nMaxAuthTries 3\n' > /etc/ssh/sshd_config.d/99-hardening.conf
[root@servera ~]# sshd -t
[root@servera ~]# sshd -T | grep -E '^(passwordauthentication|x11forwarding|maxauthtries) '
maxauthtries 3
passwordauthentication yes
x11forwarding yesOnly MaxAuthTries took effect, because nobody else set it earlier. The other two were already set (yes) by files that sort before 99, and the first value wins.
Use the right file name
Move the file to 10-hardening.conf and check again. Then validate, reload, and check the logs.
[root@servera ~]# mv /etc/ssh/sshd_config.d/99-hardening.conf /etc/ssh/sshd_config.d/10-hardening.conf
[root@servera ~]# sshd -T | grep -E '^(passwordauthentication|x11forwarding|maxauthtries) '
maxauthtries 3
passwordauthentication no
x11forwarding no
[root@servera ~]# sshd -t && systemctl reload sshd
[root@servera ~]# systemctl is-active sshd
activeTest a new login
In a third terminal on workstation, try to log in as ops with a password only (-o PubkeyAuthentication=no), then with the key ~/.ssh/id_ops. This requires the key from the keys exercise.
[student@workstation ~]$ ssh -o PubkeyAuthentication=no ops@servera true
ops@servera: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
[student@workstation ~]$ ssh -i ~/.ssh/id_ops ops@servera 'echo key login still works'
key login still worksPasswords are refused; the key works. (If you had not set up keys first, you would have locked ops out: that is why the spare session matters.)
Look at the log
On servera, show the last log lines of sshd.
[root@servera ~]# journalctl -u sshd --no-pager -n 4 | cut -c40-
sshd-session[1049]: Accepted publickey for ops from 172.25.251.9 port 41346 ssh2: ED25519 SHA256:5AQb...
sshd-session[1049]: pam_unix(sshd:session): session opened for user ops(uid=1001) by (uid=0)Grade and finish
Check your work with lab grade sa-hardening, then put the exercise away with lab finish sa-hardening.