SSH Fundamentals for Support: Key-Based Auth Done Right
Remote Support Tools & Techniques
Chapter 2 · SSH Fundamentals for Support: Key-Based Auth Done Right
This site's own Remote Access With SSH (ssh1) course covers SSH's full mechanics. This chapter stays narrowly focused on the practices a support engineer needs to get right every day: why key-based authentication is the standard, one rule that's genuinely non-negotiable, and reading a system's own access list as real diagnostic evidence.
Why Key-Based Auth Over Passwords
SSH key-based authentication uses a public/private key pair — the private key never leaves your own machine, and authentication happens through a cryptographic challenge rather than transmitting a secret over the connection at all. Two real, concrete advantages: nothing secret ever crosses the wire to be intercepted or brute-forced, and access is revocable per person — removing one person's public key from a system doesn't affect anyone else's access, unlike a shared password that has to be rotated for everyone the moment one person leaves.
The Mechanics, Briefly
The public key (.pub) is what gets added to a target system's ~/.ssh/authorized_keys. The private key stays exactly where it was generated.
The Cardinal Rule: Never Share a Private Key
log1's own first chapter. It also makes revocation all-or-nothing — if the key leaks, or one person leaves, everyone's access breaks and has to be re-issued at once. Each person should have their own keypair; access is granted by adding their own public key to a system, never by distributing a private one.
Passphrase-Protecting Your Private Key
A private key file with no passphrase means anyone who obtains a copy of the file itself — a stolen laptop, a leaked backup — can use it immediately, with no further barrier at all. A passphrase adds a genuine second layer, at the real cost of needing to enter it (or caching it for a session via an ssh-agent). This isn't an absolute mandate for every scenario — some automated, non-interactive use cases genuinely can't use a passphrase-protected key and need other compensating controls instead — but for a support engineer's own personal, interactive key, a passphrase is the sensible default.
Reading authorized_keys Like Evidence
A system's own ~/.ssh/authorized_keys file is itself a legitimate diagnostic artifact, in the exact same spirit as log1's own "read it" discipline — each line is one authorized public key, and checking who currently has access to a system can be as simple as reading this one file directly. Genuinely useful during onboarding/offboarding verification, or when investigating "how did they get in" during a security incident.
Before — unlabeled, effectively unauditable:
After — a clean, identifying comment on every key:
The "before" version is three anonymous, uninterpretable lines — nobody could confidently answer "who is this?" months later. The "after" version answers it directly, on sight, for anyone who ever needs to.
Hands-On Exercises
Explain why key-based SSH authentication is considered more secure than password authentication, using this chapter's own two stated advantages.
📄 View solutionExplain both problems this chapter identifies with a team sharing one private key, and why the first one connects directly back to log1's own evidence-based diagnosis theme.
Using this chapter's before/after authorized_keys example, explain what specifically makes the "after" version more useful, and in what real situation that difference would actually matter.
Chapter 2 Quick Reference
- Key-based auth: nothing secret crosses the wire, and access is revocable per person, not all at once
- Never share a private key — one keypair per person, access granted by adding a public key, not distributing a private one
- A shared key destroys per-user accountability and makes revocation all-or-nothing
- Passphrase-protect your own interactive key as the sensible default — a bare key file is usable by anyone who obtains it
authorized_keysis itself a diagnostic/audit artifact — read it directly to see who currently has access- Label every key with a clear, identifying comment — an unlabeled key is effectively unauditable months later
- Next chapter: SSH Beyond a Plain Shell: Port Forwarding & Jump Hosts