In this lesson, you will learn how to harden your physical terminal access by requiring additional authorization layers for anyone sitting directly at the system console.
Even with robust network security, a system is physically vulnerable if an unauthorized user can simply walk up, plug in a keyboard, and interact with a root-level terminal. When we speak of "Securing the System Console," we are moving beyond standard password prompts to ensure that the console itself is tethered to a physical trust chain.
Restricting Access via PAM
The first line of defense is modifying the Pluggable Authentication Modules (PAM) stack specifically for login or tty sessions. We can utilize pam_securetty.so to restrict root access to specific, pre-approved physical terminals (tty), but for advanced lockdowns, we often require hardware-backed authentication.
You can modify /etc/pam.d/login to require a physical token, such as a FIDO2 security key, even for local console logins. By adding a line like this to your configuration, you ensure that even someone with the physical keyboard must also provide a secondary physical hardware secret:
# Require FIDO2 key for physical console logins
auth required pam_u2f.so cue console
Disabling Emergency Access
Beyond PAM, the console's vulnerability often lies in the GRUB bootloader or single-user mode. If an attacker can reboot the machine, they can modify kernel parameters (like adding init=/bin/bash) to gain root shell access without entering a password. To prevent this, you should lock down the GRUB configuration:
- Password-protect GRUB: Generate a salted password hash and add it to
/etc/grub.d/40_custom. - Disable Ctrl-Alt-Del: Prevent a physical attacker from triggering a reboot or system halt by masking the target in systemd:
systemctl mask ctrl-alt-del.target
By disabling the ability to reboot into maintenance modes and forcing hardware-backed authentication at the physical TTY level, you transform the system console from an open door into a managed access point. This ensures that physical proximity does not automatically equate to administrative privilege.
Key Takeaway: Securing the physical console requires combining PAM-based hardware authentication with systemd and bootloader restrictions to prevent unauthorized local sessions and bypass attempts.