Linux · Lesson 04
Passwords, Authentication & Account Policies
Review password state, account expiration, password aging, PAM, SSH authentication, and effective access without locking out required users or breaking service identities.
Authentication is a system of layers. A secure competition image requires more than memorizing password values. You need to know which policy applies, which users require access, which services depend on identities, and how to verify the final behavior.
Lesson Snapshot
Learning objectives
Understand the authentication system before changing policy
Explain how Linux password state, aging, authentication, PAM, and account locking relate to one another.
Inspect local password policy and account state before changing values.
Distinguish password locking, account expiration, shell restrictions, and authentication-method controls.
Use password-aging tools without assuming one universal competition value fits every scenario.
Understand where PAM fits into authentication and why careless PAM edits can lock out authorized users.
Verify that required users can still authenticate after policy changes while unnecessary access is reduced.
Core idea
Authentication is layered
An account can be present, have a locked password, still possess an SSH key, run a service, or retain an active session. Treat password state, account state, PAM, and service-specific authentication as related but separate controls.
Authentication risk
A correct-looking policy can still break the mission
Password aging, PAM, SSH, and account expiration can deny access to authorized users or service identities if changed blindly. Apply scenario-driven policy and verify the exact access path afterward.
Authentication fundamentals
Six concepts to separate before troubleshooting
Password state
A local account can have a usable password, a locked password, no password, or another state reflected in shadow metadata. Password state is only one part of whether the account can access the system.
Password aging
Linux can track when a password was last changed and apply minimum age, maximum age, warning periods, and expiration behavior.
Account expiration
An account can be configured to expire independently of ordinary password aging. This is different from merely locking the password hash.
Authentication stack
Applications such as login, sudo, and SSH can use PAM modules and service-specific configuration. A password policy may therefore be enforced in more than one place.
Multiple access methods
A user might authenticate with a password, SSH key, cached session, service token, or another configured method. Disabling one path does not automatically remove all access.
Scenario-driven policy
The correct policy depends on the scenario, system role, authorized users, and required services. Avoid forcing remembered values without evidence.
Important configuration sources
Know where policy can come from
/etc/shadowStores local password hashes and password-aging fields for local accounts.
Caution
Highly sensitive. Do not expose hashes or copy them unnecessarily. Use account-management tools for normal review and changes.
/etc/login.defsContains defaults used by some account-management tools, including password-aging defaults for newly created accounts.
Caution
Changing a default does not necessarily retroactively update every existing account.
/etc/pam.d/Contains PAM service configuration used by applications such as login, sudo, and other authentication-aware programs.
Caution
A bad PAM change can deny access to legitimate users. Read the service stack and module behavior before editing.
/etc/security/Contains configuration used by several PAM and security modules, depending on what is installed.
Caution
Not every file applies to every system. Confirm the active module and service stack.
/etc/ssh/sshd_configControls SSH server behavior, including authentication methods and remote-login restrictions.
Caution
SSH policy is separate from local console authentication. Preserve required remote access and validate changes before restart.
/etc/ssh/sshd_config.d/Drop-in SSH configuration directory on systems that use it.
Caution
Effective SSH settings can come from multiple files. Inspect the final configuration rather than one line in one file.
Inspection first
Describe account and policy state before changing it
sudo passwd -S usernameShow password status and selected aging information for a local account.
sudo chage -l usernameDisplay password-aging and expiration settings for an account.
sudo getent shadow usernameInspect the shadow record when elevated access is appropriate. Avoid exposing hash data unnecessarily.
grep -E '^(PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE)' /etc/login.defsReview account-creation defaults related to password aging.
grep -R 'pam_pwquality\|pam_pwhistory\|pam_faillock' /etc/pam.d 2>/dev/nullLook for common PAM modules related to password quality, history, or failed-authentication handling where installed.
sudo sshd -T 2>/dev/null | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication'Inspect effective SSH authentication settings when the OpenSSH server is installed.
getent passwd usernameReview the account shell and home directory alongside authentication state.
lastlog -u usernameReview the recorded last-login indicator where available. Treat it as supporting evidence, not perfect proof.
Protect password hashes
Shadow data is sensitive authentication material. Inspect only what is needed for authorized administration and do not publish, share, or copy password hashes into notes or screenshots unnecessarily.
passwd status
Read the state carefully
PThe account has a usable password according to passwd status output.
LThe password is locked.
NPNo password is set for the account.
Output can vary across distributions and versions. Use the local manual page when a field or status marker is unclear.
Password aging
Six fields that need context
Last password change
When the current password was last changed according to local account metadata.
A timestamp does not tell you whether the password itself is strong.
Minimum password age
How soon a password may be changed again.
Very restrictive values can interfere with legitimate password resets or recovery workflows.
Maximum password age
How long the password may remain valid before expiration behavior applies.
Do not impose a remembered number unless the scenario or policy requires it.
Warning period
How far in advance the user may be warned that the password is nearing expiration.
Warnings affect usability, not password strength by themselves.
Inactive period
How long after password expiration an account may remain usable before additional disabling behavior occurs, depending on configuration.
This can affect required users unexpectedly if set without context.
Account expiration
Date after which the account itself is considered expired.
This is distinct from password expiration and should match the scenario.
Authentication layers
Trace access from account to application
Account existence
Does the account exist, and is it authorized by the scenario?
Useful sources
getent passwd, id, account inventory
Password state
Is the password usable, locked, or absent?
Useful sources
passwd -S, shadow metadata
Password aging
Are expiration, minimum age, maximum age, and warning values intentional?
Useful sources
chage -l, login.defs
PAM
What authentication and account-control modules are actually used by the relevant service?
Useful sources
/etc/pam.d/, active module configuration
Application/service policy
Does SSH, sudo, login, display manager, or another service add its own restrictions?
Useful sources
sshd -T, sudo policy, service configuration
Alternate authentication
Could SSH keys or another configured method still allow access even when password login is restricted?
Useful sources
~/.ssh/authorized_keys, sshd effective configuration, service-specific settings
PAM
Powerful authentication plumbing that deserves caution
PAM is modular
Pluggable Authentication Modules let services share authentication, account, password, and session controls through configurable module stacks.
Service files matter
Different applications can use different files under /etc/pam.d/. A setting that affects login may not be identical to one affecting sudo.
Order matters
The order and control flags of PAM modules can change the resulting authentication behavior.
Installed modules vary
Modules such as pam_pwquality, pam_pwhistory, and pam_faillock may or may not be installed or active on a particular image.
Policy can have dependencies
A strict rule may affect service accounts, scripted workflows, recovery, or authorized users if applied without context.
Validate before logout
After authentication-related changes, verify a second authorized access path before closing the working administrative session when practical.
Do not treat PAM as a copy-and-paste checklist
Different images may have different modules installed, different service stacks, and different required authentication behavior. Learn what the existing stack does before you change it.
Scenario reasoning
The same policy does not belong on every account
Account
Morgan
Scenario
Only authorized administrator; local and SSH access required.
Observed
Password usable, expected sudo privilege, SSH password authentication currently enabled.
Reasoning
Preserve required access. Review policy and SSH exposure without locking out the administrator.
Account
Avery
Scenario
Authorized standard user.
Observed
Password active; account does not expire; no administrative privilege.
Reasoning
No automatic change is justified. Compare aging settings with the stated policy.
Account
Riley
Scenario
Authorized standard user.
Observed
Password locked unexpectedly; scenario requires normal login.
Reasoning
Investigate why the account is locked and restore only the required authentication path if appropriate.
Account
guest-temp
Scenario
Not authorized.
Observed
Password active and interactive shell enabled.
Reasoning
High-priority investigation. Preserve evidence, confirm the account is unauthorized, then choose the least disruptive containment/removal path.
Account
backupsvc
Scenario
Not named directly; backup service is required.
Observed
Password locked, non-interactive shell, service uses the account.
Reasoning
Likely normal service-account design. Do not unlock or disable based only on human-user expectations.
Controlled changes
Use account tools instead of manual file surgery
Goal
Lock a local password
Example
sudo passwd -l usernameCaution
This locks the local password hash but may not disable SSH keys, existing sessions, services, or every authentication mechanism.
Goal
Unlock a local password
Example
sudo passwd -u usernameCaution
Use only when the account is authorized and a usable local password is required.
Goal
Force password change at next login
Example
sudo chage -d 0 usernameCaution
Only use when the scenario or policy calls for it and the user can actually complete the required login flow.
Goal
Set an account expiration date
Example
sudo chage -E YYYY-MM-DD usernameCaution
Use a scenario-driven date. Do not invent an expiration requirement.
Goal
Remove account expiration
Example
sudo chage -E -1 usernameCaution
Use only if the account is authorized and should not expire under the scenario.
Goal
Review/edit password aging
Example
sudo chage usernameCaution
Interactive chage can modify several fields. Record the original values and change only those justified by policy.
Dangerous shortcuts
Authentication mistakes that can lock out the team
Setting the same aging values on every account
Service identities and required human users can have different needs, and the scenario may specify exceptions.
Editing /etc/shadow manually
A formatting mistake can break authentication or corrupt account state. Use account-management tools for normal changes.
Changing PAM from memory
PAM syntax, modules, and stack behavior are easy to misconfigure and can lock out authorized users.
Assuming passwd -l disables the whole account
Other access mechanisms may still work. Verify SSH keys, services, scheduled jobs, and active sessions where relevant.
Disabling SSH password authentication without checking keys
Required remote administration can be lost if no verified alternate authentication method exists.
Logging out immediately after auth changes
You may discover the new policy blocks every authorized administrative path only after your working session is gone.
Evidence sources
Build authentication decisions from multiple sources
passwd status
sudo passwd -S usernameLocal password state and selected aging information.
chage
sudo chage -l usernameDetailed password-aging and account-expiration values.
SSH effective configuration
sudo sshd -TEffective SSH server configuration after includes and defaults are processed.
PAM configuration
grep -R 'pam_' /etc/pam.d 2>/dev/nullWhich PAM modules appear in service stacks. Interpretation still requires context.
Authentication logs
sudo journalctl --since today | grep -iE 'authentication|failed|sudo|sshd'Recent authentication-related evidence where messages are present in the journal.
Login history
lastRecorded login sessions from wtmp where available.
Verification
Prove both policy and access
Authorized login
Confirm the intended authorized user can still authenticate through the required local or remote method.
Password state
Re-run passwd -S and confirm the intended lock/unlock state.
Aging policy
Re-run chage -l and confirm only the intended fields changed.
SSH
If SSH was affected, validate sshd configuration and test the authorized access path before ending the working session.
PAM
If PAM changed, test the exact service or authentication path the modified stack controls.
Evidence
Confirm relevant logs and account state were preserved before remediation.
Keep one known-good administrative path
When changing authentication, verify the new state before closing the working session whenever practical. That gives the team a recovery path if the new configuration behaves differently than expected.
Defensive lab
Audit a fictional Linux authentication state
Read the fictional scenario: Morgan is the only administrator and requires SSH; Avery and Riley are standard users; backupsvc supports a required backup job; guest-temp is not authorized.
Inspect passwd status and chage output for all named accounts without changing anything.
Inspect effective SSH authentication settings and verify whether SSH keys or password authentication are required for Morgan.
Review PAM files for relevant password-quality or failed-authentication modules only to understand what is active.
Classify Riley's unexpected password lock as a functionality problem, guest-temp as an unauthorized-account investigation, and backupsvc as a service identity that should not be treated like a human login.
Apply only scenario-supported changes, preserving Morgan's remote access and the required backup service.
Re-run status commands, test required authentication, review logs, and document the final state.
Lesson checklist
Before moving on
I understand the difference between password state, password aging, and account expiration.
I know that /etc/shadow is sensitive and should not be edited casually.
I can use passwd -S and chage -l to inspect an account before changing it.
I understand that /etc/login.defs contains defaults and does not automatically rewrite every existing account.
I know PAM is service-specific and that module order can matter.
I do not assume password locking disables SSH keys or every other access method.
I avoid universal password-aging values unless the scenario or policy requires them.
I validate SSH configuration and preserve required remote access after authentication changes.
I preserve authentication evidence before remediation.
I verify the exact access path affected by the change before considering the work complete.
Reflection
Check your reasoning
Question 1
Why is password locking different from account expiration?
Question 2
Why can an account with a locked password still matter to a running service?
Question 3
Why is /etc/login.defs not enough to determine the effective policy of every existing account?
Question 4
What makes PAM changes especially risky during competition work?
Question 5
Why should SSH authentication be tested before closing the current administrative session?
Question 6
What should you verify after changing password-aging or account-expiration settings?
Carry this forward
Secure authentication means the right identities can use the right access methods under the right policy. Avoid one-size-fits- all values, preserve service dependencies, and test the exact login path after every meaningful change.