Network Security, Authentication, and Access Control
This domain tests authentication, authorization, cryptographic trust, and access control for Unix network services. CUNP questions often ask why an SSH key is rejected, why a TLS client fails verification, or how PAM and sudo interact with service access.
Core rules and concepts
- Authentication proves identity; authorization decides what that identity may do. A valid login does not imply permission to run a command or read a file.
- PAM stacks modules in order for auth, account, password, and session management. The first required failure can stop the stack; sufficient and optional controls behave differently.
- SSH public-key authentication depends on ownership and permissions. The user's ~/.ssh should normally be 700, authorized_keys 600, and both owned by the user, not group- or world-writable.
- Host keys identify servers. Clients store known hosts and warn on changes; disabling StrictHostKeyChecking weakens trust.
- TLS verification checks the certificate chain, hostname, validity dates, and trust anchors. A successful TCP connection does not prove TLS trust.
- sudo policy lives in sudoers and included files; use visudo to validate syntax. SELinux and AppArmor add mandatory access control beyond Unix modes.
- Least privilege means narrow capabilities, dedicated service accounts, and restricted network exposure.
Worked example
An SSH key login fails with Permission denied (publickey). Confirm the server has PubkeyAuthentication yes and the correct AuthorizedKeysFile. On the client, run ssh -vv to see which key is offered. On the server, check home-directory permissions, .ssh and authorized_keys ownership and modes, and the SSH log. If the key is offered and rejected, compare the public key fingerprint with authorized_keys. If no key is offered, inspect ssh-agent and IdentityFile. Fix ownership and modes rather than setting 777.
Traps that cost marks
Do not disable password authentication before key login works. Do not confuse a TLS handshake with certificate validation. Do not treat group membership as equivalent to sudo rights, or Unix mode bits as the only access control. Check logs for the exact denial reason.
Exam focus
Separate identity proof, policy decision, and enforcement. Verify permissions, PAM order, sudoers syntax, and security-module denials with evidence.