Bootcamp Module 3: Users & SSH

Access is oxygen. This module covers accounts, sudo, and SSH keys — plus how to fix the inevitable Permission denied (publickey) without panic.

Bootcamp hub · Prev: Module 2

Learning goals

  • Create a human user and grant sudo thoughtfully
  • Generate and install an ed25519 keypair
  • Understand ~/.ssh permissions
  • Use console break-glass before tightening sshd

Core drills

Read and apply (lab only first):

Lab

  1. Create user labadmin, add to sudo/wheel.
  2. Install your public key; SSH in as that user.
  3. Keep a second session open; practice a harmless sshd reload.
  4. Intentionally break permissions on a lab authorized_keys and fix via console/virt manager.

Next: Module 4 — Services & disks →

Account hygiene

  • One human, one login identity
  • Shared accounts only for break-glass with audit
  • Disable/expire leavers the same day HR says so
  • Prefer groups for sudo rights over editing sudoers per person ad hoc

SSH key lifecycle

  1. Generate on your laptop (ed25519)
  2. Store private key in an agent / password manager SSH agent
  3. Install public key via your team’s source of truth
  4. Rotate when lost, leaked, or on schedule
  5. Remove keys for leavers promptly

Lockout avoidance drill

Before any sshd hardening change: open console, open second SSH session, run sshd -t, reload, test a new connection before closing the old one. Memorize that order.

Mini incident tabletop

“You get Permission denied (publickey) after a laptop reinstall.” Walk the publickey checklist aloud. Then skim the hardening checklist and mark which items you’ve actually done on your lab VM.

Stretch

Add a non-default SSH port on the lab only, update firewall, document it, then decide whether the noise reduction is worth the hassle (usually optional).

sudoers without footguns

Use visudo. Prefer drop-in files under /etc/sudoers.d/. Grant specific commands when practical; avoid NOPASSWD:ALL on production humans unless you have a strong inventory reason and compensating controls.

Bastion pattern (concept)

Humans SSH to a hardened bastion; private app nodes accept keys only from that bastion or don’t accept human SSH at all (SSM, etc.). Even in a homelab, drawing that diagram changes how you think about exposure.

Quiz

  1. Why keep a session open while reloading sshd?
  2. What permission should authorized_keys have?
  3. Name two break-glass paths besides “ask a friend to SSH.”

Extended lab: harden then recover

On lab only: set up key auth for labadmin, disable password auth, reload sshd with a second session open. Then revoke the key deliberately and recover using hypervisor console. Time yourself. Faster recovery next week is the metric.

Anchor docs: hardening, publickey denial.

Permissions quick reference

~/.ssh          700
authorized_keys 600
private key     600 (never 644)
public key      644 is fine

Ownership must match the user. Root-owned authorized_keys in a user home is a common self-own after hasty sudo edits.

Team habits

Even as a solo learner, practice as if you have teammates: name your keys, document the bastion, store break-glass steps in a password manager. Solo labs that mimic team process transfer cleanly to jobs.

ssh-agent practicality

Load a key once per session with ssh-add. On desktops, OS agents or password-manager agents reduce passphrase fatigue without writing passphraseless keys to disk. Never copy private keys to servers “for convenience.”

AllowUsers and why it surprises people

If sshd has AllowUsers alice and you create labadmin, keys won’t save you. Effective config via sshd -T is the source of truth — not memory.

Connecting the dots to DevOps

User and SSH baselines are the first Ansible roles most teams write. When you finish Module 6, revisit this module’s lab as code. Until then, manual competence matters — automation without understanding ships lockouts faster.