Every command in this subject's other five courses — a pg_stat_activity query, a top snapshot, a curl -v — assumed a terminal was already open on the right machine. This course is about the step that made that possible in the first place: getting there, safely, and knowing what genuinely changes when the machine — or the person sitting at it — isn't yours.

What the Other Five Courses Silently Assume

None of them teach how that access actually gets established. This course fills exactly that gap.

Three Genuinely Different Kinds of "Getting There"

Genuinely different tools, genuinely different trust models, genuinely different risks — the capstone applies all three to fresh scenarios of their own, mirroring this course's own three-part structure directly.

Why "Just Connect" Isn't as Simple as It Sounds

Remote access tools make a costly mistake trivially easy — connecting to the wrong host because two sessions look identical, carrying more privilege than a purely diagnostic task ever needed, or, for end-user screen sharing, taking control of someone's machine without them fully understanding what you can see and do. This course is as much about doing remote support safely as it is about doing it at all.

This course doesn't replace this site's own Remote Access With SSH (ssh1), Remote Desktop: RDP & VNC (rdp1), or VPN (vpn1) courses — it applies and extends their material specifically for the support-diagnostic context those courses don't focus on.

What This Course Covers

SSH key-based authentication done right, port forwarding and jump hosts, RDP/VNC and modern remote-desktop alternatives, the different trust model end-user screen sharing requires, least privilege applied to your own access, working safely on a system you don't own, diagnosing a connection that won't even establish, and session logging. The capstone applies all of it to three fresh scenarios.

Hands-On Exercises

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

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.

Hands-On Exercises

A plain shell is only one thing SSH is good for. This chapter covers two techniques a support engineer runs into constantly: reaching a service that was deliberately never exposed directly, and connecting through a hardened gateway to internal servers you can't reach straight from the internet.

Local Port Forwarding: Reaching a Service That Isn't Exposed

This forwards your own machine's local port 5432 through the SSH connection to port 5432 as seen from the remote side — commonly its own localhost, reaching a service that's only listening internally on that server, never exposed to the outside at all. Once the tunnel is open, connecting a local client to localhost:5432 on your own machine transparently reaches the remote database.

Why Services Are Often Not Directly Exposed — And Why That's Good

A database listening only on localhost, reachable by nothing outside that one machine, is a deliberate security practice — the same reasoning Network Troubleshooting covers for firewall rules: reducing the attack surface by not exposing anything that doesn't genuinely need to be reachable from outside. SSH port forwarding is the sanctioned way to reach such a service for legitimate diagnostic work, without weakening that security posture by opening the port more broadly to make things convenient. The "obstacle" of not being directly reachable is the control working exactly as intended — tunneling through SSH works with it, not around it.

Remote Port Forwarding: The Reverse Direction

ssh -R reverses the direction — exposing a port on your own machine so the remote side can reach it. Less common for this course's own use cases than local forwarding, but worth knowing it exists: it's the right tool when a remote system needs to temporarily reach something running locally on your machine, rather than the other way around.

Jump Hosts and Bastion Hosts

Many organizations don't allow direct SSH access to internal servers from the general internet at all — instead, one hardened, carefully monitored "jump host" (or bastion host) is the only machine reachable from outside. You connect to it first, then reach the actual target from there. The modern, clean way to do this in one step:

Concentrating the exposed attack surface onto one well-monitored machine, rather than every internal server needing to individually defend itself against internet-facing attacks, is exactly the same logic behind not exposing the database port directly.

Combining Both: ProxyJump Plus Port Forwarding

One command: connect through the bastion, land on the database server, and forward its localhost-only database port to your own machine — all in a single line.

Simplifying Repeated Use With ~/.ssh/config

With this saved, ssh db-server alone does everything the full command above did.

Working Example: A Production Database, Reachable Only Through a Bastion

A diagnostic query needs to run directly against a production database that's only reachable via an internal bastion, and only listens on localhost on the database server itself:

A read-only diagnostic query, run against a database that was never directly exposed, using exactly the sanctioned path — and the tunnel explicitly closed the moment the work is done.

Hands-On Exercises

Chapters 2 and 3 covered SSH — command-line access. This chapter covers the scenarios that genuinely need a GUI instead: a Windows admin tool with no CLI equivalent, a legacy application only usable through its desktop interface, or visually confirming a display issue no remote command can fully capture.

RDP: Windows-Native, Encrypted, Efficient

RDP (Remote Desktop Protocol) is built into Windows, and encrypted by default (TLS-based) in modern versions. A real, genuine technical advantage: RDP sends drawing instructions and screen deltas rather than raw video frames, generally making it more bandwidth-efficient than VNC's typical full-framebuffer approach. Practically, the target account usually needs explicit RDP access granted — membership in the Remote Desktop Users group — a standard, deliberate admin step, not something that happens by default.

VNC: Cross-Platform, But Check the Implementation

VNC works across Windows, macOS, and Linux — genuinely cross-platform, unlike RDP's Windows-native server side. But VNC's own security posture varies significantly by implementation: some VNC servers have historically shipped with weak encryption, or none at all, by default. "VNC" isn't one single security guarantee the way modern RDP roughly is — it depends heavily on which specific server and client you're using and how it's configured.

Modern Alternatives: TeamViewer, AnyDesk, Chrome Remote Desktop

These tools are generally not what you'd reach for to administer infrastructure you already have RDP/VNC/SSH access to — they solve a genuinely different problem: an ad-hoc session with an end user's own machine, often sitting behind NAT or a firewall with no direct network path available at all. Both sides connect outward to the vendor's own relay servers, meeting there — avoiding any need for inbound firewall rules on either end. This relay model is exactly what makes them practical for helping a random end user, and it's also what sets up Chapter 5's own "different trust model" material directly.

A Clear Decision Table

Working Example: A GUI-Only Disk Management Tool

A storage issue on a Windows server needs investigating with its own Disk Management tool — no convenient CLI equivalent exposes the same information, the kind of scenario System Monitoring & Performance Diagnosis's own disk-space material assumes a shell for, but this specific tool genuinely doesn't have one. The correct path: connect through the organization's VPN or jump host first, then RDP to the target server from there — never RDP directly to a server exposed on the open internet, confirming the connection is going through the sanctioned path before doing anything else.

Hands-On Exercises

Chapters 2 through 4 all connected to infrastructure — the "user" of the system, in every meaningful sense, was the system itself, with nobody watching. This chapter is different in kind: there's an actual person present, often non-technical, whose own machine and whose own visible desktop are being accessed while they watch. Everything in this chapter follows from that one fact.

Informed Consent Isn't Just "They Clicked Allow"

Technically possible isn't the same as genuinely consented to. A user clicking "Allow" because a support agent told them to, without actually understanding what that agent can now see or do, isn't informed consent in any meaningful sense. Good practice: explain plainly, before starting — will you see their whole screen or just one window? Will you only be able to look, or will you be able to move their mouse and type? Say it before they grant access, not after.

View-Only vs. Full Control

Most screen-sharing tools offer both: view-only (you can see, not interact) and full remote control (you can move the mouse, click, type). Default to the least access that accomplishes the task — if you only need to see an error message or confirm a setting, view-only is enough and far less invasive. Only escalate to full control when you genuinely need to act yourself, ideally after explaining why. This is Chapter 6's own least-privilege principle, applied directly to a human-facing context rather than an infrastructure one.

Transparency During the Session

Narrate what you're doing as you do it — "I'm going to open your Control Panel now to check a setting" — rather than silently clicking around on someone else's machine. This keeps the user genuinely informed and comfortable, and it has a real secondary benefit: it helps them understand what actually happened, rather than leaving them a passive bystander on their own computer.

Ending the Session Cleanly

Fully disconnect at the end — don't just close your own window while a remote-control agent is still technically running and listening on their machine. Confirm the session shows as ended on both sides. If a persistent helper agent was installed specifically for this one session, uninstall it afterward if it isn't meant to remain.

What to Do If Something Seems Off

If, during a session, something looks like a sign of a pre-existing compromise — unfamiliar browser extensions, obviously malicious software, other signs the machine may already be infected — this shifts the situation from routine support into something that needs escalating differently, per Incident Response & Ticketing Workflows' own escalation material. Worth acknowledging honestly rather than pretending it never happens, without turning this chapter into the still-outstanding, separately-scoped Security Basics for Support Technicians course.

Working Example: A Complete Support Session

Hands-On Exercises

Chapters 1 and 5 both previewed this: use the minimum access that accomplishes the current task, nothing more, even when broader access is technically sitting right there and available to you. "Even for yourself" is the important part — this applies to your own habits as a support engineer, not just what gets granted to other people.

Why Broad Access Is a Risk Even If You'd Never Misuse It

Least privilege isn't (only) about not trusting yourself. A broadly-privileged account is a bigger target and a bigger blast radius the moment something goes wrong with your access specifically — a stolen credential, a phished session, a compromised laptop — entirely independent of your own intentions. The real question isn't "would I misuse this," it's "what's the maximum damage if something goes wrong with my access, regardless of why."

Read-Only Where Read-Only Suffices

Many diagnostic tasks genuinely only need read access — checking logs, checking metrics, running a SELECT. Using a dedicated read-only account or role for these, rather than a full admin account that happens to also be capable of it, is a real, practical default. Web & Application Troubleshooting's own worked examples already modeled this directly — its readonly_user connecting for a diagnostic query, not the application's own full database credentials.

Time-Limited Credentials Over Standing Access

Where the infrastructure supports it, short-lived credentials — a bastion host issuing a certificate valid for a few hours rather than a permanent keypair, a cloud provider's own temporary session tokens — are genuinely stronger than permanent standing access. If a short-lived credential leaks, the exposure window is naturally bounded; a permanent one keeps working until someone notices and explicitly revokes it. Not every organization has this kind of infrastructure built out yet, and standing access used with good discipline is still far better than no discipline at all — this describes a genuinely stronger option where it's available, not a judgment on anyone whose organization hasn't built it.

Elevation on Demand, Not Standing Root

Using sudo for the specific command that genuinely needs elevated privilege, rather than logging in as root directly or holding a permanent root shell, is the same "escalate only for the moment you need it" principle applied to everyday Linux access.

The Temptation to Over-Provision "Just in Case"

A genuinely understandable, common failure mode: reaching for broader access than a specific task actually needs because asking again later feels like friction, or "I might need it soon anyway." This undermines the whole principle through a thousand individually-reasonable-feeling small decisions, not one dramatic one. If a genuine, recurring need for broader access exists, that's worth requesting as real, properly-scoped standing access through the normal process — not quietly worked around by defaulting to an overpowered account out of convenience.

Working Example: Diagnosing a Slow Service

Same diagnostic work, same actual outcome — a dramatically smaller blast radius the entire time it was happening.

Hands-On Exercises

Earlier chapters covered getting access. This one is about what happens once you have it — specifically on a system that belongs to someone else's team, where the ordinary confidence of working on your own infrastructure doesn't automatically apply.

Confirming Authorization and Scope Before Touching Anything

Before making any change — not just diagnosing — on a system that isn't yours to freely administer, confirm explicitly: who actually owns this system, what are you authorized to do on it (read-only diagnosis? specific fixes? anything at all?), and is there a change-approval process that applies here. This is a genuinely different question from "do I have access" — having access and being authorized for a specific action are not the same thing.

The Trivially-Easy Mistake: Wrong Host, Wrong Session

Remote access tools make it genuinely easy to lose track of which session is connected to which host, especially with several near-identical terminal or RDP windows open side by side. A command meant for staging, accidentally run against production because the wrong window happened to have focus, is a classic and genuinely damaging mistake — not a rare, exotic failure.

A Practical Habit: Read the Prompt Before You Type

Literally look at the shell prompt — typically user@hostname — immediately before running any command that changes state, not just once at the start of a session. This is the single cheapest check against the wrong-host mistake, and it's worth building as a deliberate habit precisely because it's easy to stop doing once a session feels routine.

Dry Runs and Confirmation Prompts

Many tools support a dry-run or "show what would happen" mode — rsync --dry-run, a package manager showing its plan before applying it. Using these before the real action, especially on an unfamiliar or high-stakes system, catches a mistake before it happens rather than after. Related: don't habitually bypass built-in confirmation prompts (scripting -y or --force by default) specifically on systems you don't own or aren't deeply familiar with — the extra friction of a confirmation prompt is doing genuinely useful work in exactly this scenario.

When in Doubt, Ask — Even If It Feels Slow

On an unfamiliar system, especially one owned by another team, asking "can you confirm it's safe to do X here" before acting isn't a sign of incompetence — it's good practice, the same discipline Incident Response & Ticketing Workflows already applied to escalation timing: acting alone past the point where checking would be faster costs more than the moment spent asking.

Documenting What You Did, Even Outside a Formal Incident

Even for routine work — not a formal incident — briefly noting what you changed on a system you don't own, and when, and why, is genuinely valuable for the team who actually owns it, since they'll otherwise have no record of why their system's state changed. A lightweight version of Chapter 5's own live-timeline discipline, applied to any change on someone else's system, not only formal incident response.

Working Example: A Close Call, Caught in Time

An engineer is about to run a cleanup script, and pauses — the practical habit from earlier in this chapter — to read the prompt first: root@prod-db-3, not the expected root@staging-db-1. The mistake is caught before anything runs. A brief, blameless note goes to the team anyway: what nearly happened, and why — not to assign fault, but because a near-miss is exactly the kind of information worth sharing, in the same spirit as Incident Response & Ticketing Workflows' own blameless review. Hiding it out of embarrassment would only mean the same near-miss is more likely to happen again, to someone else, with no warning.

Hands-On Exercises

Network Troubleshooting already taught the general diagnostic toolkit — DNS, ping, port checks, firewalls. This chapter isn't new technical territory so much as that same toolkit aimed at one specific, narrower question: "I'm trying to reach an SSH, RDP, or VNC service on a specific host, and it isn't working."

The First Question: Is It Me, or Is It Them?

The same scoping instinct netdiag1 opens with, applied here directly: can you reach other things fine? If yes, the problem is specific to this one host or service, not your general connectivity. Testing from a genuinely different network — your phone's own mobile data, for instance — isolates whether the problem is your specific location or something about the target itself.

Common SSH Connection Failures, Precisely Read

Reusing netdiag1's own "refused vs. timed out" distinction (Chapter 6), applied specifically to SSH:

A Practical Checklist, In Order

1. Can I reach anything else at all? (scope)
2. Can I reach the host at the network level — ping, or a route that completes? (netdiag1 Chapter 5)
3. Is the specific port actually open? (netdiag1 Chapter 6 — nc -zv host 22 for SSH, nc -zv host 3389 for RDP)
4. If the port is open but the connection still fails — is this actually an authentication problem, not a network one? (Chapter 2's own authorized_keys material)

RDP-Specific Connection Failures

RDP has its own distinct failure modes worth recognizing on sight, rather than mistaking for a network problem: "The remote computer requires Network Level Authentication, which your computer does not support" is a real, specific, named error indicating a client/server security-mode mismatch — not a connectivity issue at all. Similarly, a connection refused specifically due to a server already at its concurrent RDP session limit is a licensing/capacity condition, again nothing to do with the network path.

Working Example: "SSH to the Jump Host Stopped Working This Morning"

Working the checklist: other services reach fine — not a general network problem. A ping to the jump host times out. A traceroute shows the path dying at the exact same hop that always used to pass through cleanly — genuine network-path evidence, not an SSH-specific issue at all. This gets escalated as a plain netdiag1-style network finding to the network team, rather than treated as an SSH problem — "I can't SSH in" often turns out to be an ordinary network-layer problem wearing an SSH-shaped disguise, and the diagnostic techniques from that course apply completely unchanged.

Hands-On Exercises

This chapter closes the content chapters where it makes sense to: access itself is worth logging, for exactly the same "evidence over guesswork" reason this whole subject has been built on since log1's own first chapter — not surveillance of the support engineer, the same principle applied one layer earlier, to how a session even started.

What Gets Logged, Typically

SSH connections land in auth.log or secure — log1's own territory for where these actually live. RDP connections show up in Windows Event Viewer's own Security log, with specific event IDs for logon and logoff. For genuinely privileged or sensitive access, some organizations go further with full session recording — keystroke logging or video-style capture — through dedicated privileged-access-management tooling. Worth being honest: full session recording is a more invasive, higher-scrutiny practice, typically reserved for genuinely sensitive access, not blanket surveillance of all routine remote work.

Reading Your Own Access History Like Evidence

Checking your own recent connections is a legitimate, useful diagnostic step in its own right — confirming exactly when you connected relative to some other event, or confirming a session actually ended cleanly, the same "confirm it's actually disconnected" discipline Chapter 5 covered for screen sharing, now applied to SSH and RDP as well.

Using Session Logs During an Incident

During a genuine incident, remote-access session logs are themselves timeline evidence, per log1's own material — "who connected to this system, and when" can directly corroborate or contradict a hypothesis, the same way any other log source does. Worth noting this cuts both ways: confirming no unauthorized session occurred during a suspicious window is itself genuinely valuable, reassuring evidence — session logs are useful whether or not something bad is actually found.

Session Logging Is a Deterrent Too, Not Just a Record

Knowing that access is logged is itself a mild, healthy deterrent against exactly the kind of "just this once" shortcuts this course has warned against — sharing a private key, using a shared account, skipping least privilege. Not because anyone assumes bad faith by default, but because visibility genuinely does change behavior for the better, the same way any other accountability mechanism does. Worth stating honestly, rather than pretending logging exists purely for forensics after something has already gone wrong.

Privacy and Proportionality

Session logging should scale with the actual sensitivity of the access involved — routine read-only diagnostic access on a low-sensitivity system doesn't need the same scrutiny as privileged access to a system handling sensitive data. Organizations should be transparent with engineers about what's actually being logged and why — the same "know your organization's own policy" advice Chapter 1 opened this course with.

Working Example: "Nobody Remembers Changing This"

A sensitive configuration file changed overnight; nobody remembers doing it. Checking session logs for the exact time window shows exactly one SSH session, from one specific engineer's own key, at precisely the right time. Confirmed directly with that engineer — who then remembers making a quick, legitimate change and simply forgetting to mention it. A benign resolution, not a security incident — a realistic reminder that most mysteries logs resolve end this way, not with "aha, a breach," but with "oh right, that was me."

Hands-On Exercises

Nine chapters built the toolkit — SSH keys, tunneling, jump hosts, RDP/VNC, screen sharing's own trust model, least privilege, working safely on systems you don't own, diagnosing connection failures themselves, and session logging. This capstone returns to the three-scenario shape this subject's other diagnostic courses use, since server SSH access, GUI remote desktop, and end-user screen sharing are genuinely different tools that don't chain into one continuous story.

Scenario 1: Diagnosing a Slow Nightly Report Job via SSH

The nightly report-generation service is running unusually slowly, on a production server reachable only through a jump host.

Scenario 2: A GUI-Only Disk Check via RDP

A Windows file server shows intermittent disk errors; confirming the specific issue needs its own Disk Management tool, with no convenient CLI equivalent.

The Disk Management tool confirms a specific drive is degrading — handed off to the hardware team with the exact diagnostic evidence, rather than a vague "something's wrong with storage."

Scenario 3: Helping an End User Find a Settings Menu

A non-technical user can't locate a specific setting in their email client.

Chapter Attribution

Honest Scope Note

Hands-On Exercises