Remote access: RDP, remote assistance, SSH, and the third-party tools

Why this matters

Most support is now done at a distance, and the tool you choose determines what you can do, whether the user has to be there, and what you have just exposed. Those are three different questions and they have three different answers, but they are usually settled by one habit: whatever the technician used last time.

This lesson is about choosing deliberately. There is a genuine security dimension too — remote access is how a large proportion of real intrusions begin, not because the protocols are weak but because somebody exposed one to the internet to make their own life easier. That decision is made by support technicians, which is why it belongs here rather than only in the security objectives.

The lesson

Remote Desktop: what it needs, which editions host it, and what it disconnects

Remote Desktop gives you the machine's own desktop, as if you were sitting at it, and its characteristics follow from that.

What it needs:

• A host edition that can accept connections — Pro and above. Home can connect out and cannot host, which is the single most common surprise.
• The feature enabled, which also opens the firewall rule.
• Network reachability, and an account with permission — administrators, plus anyone in the Remote Desktop Users group.

What it disconnects is the part that catches people out. On a client edition of Windows there is one interactive session, so connecting remotely signs the local user out of their screen. Anyone sitting at the machine sees it lock. This makes it the wrong tool for helping a user with something — they cannot watch, and they cannot tell you what they were doing — and the right tool for working on a machine nobody is using.

That distinction is the whole of the choice in this objective: Remote Desktop is for administering a machine, and the assistance tools in the next section are for helping a person.

Two practical notes. The connection carries clipboard, printers and drives if you let it, and the checkboxes for that are in the client's options — useful, and worth thinking about before connecting to a machine you do not trust. And the default port is well known, which matters a great deal in the last section of this lesson.

Remote assistance and quick assist, and when a user must be present

Two tools exist for the case where the user is sitting in front of the machine and needs help with what is on their screen.

Remote Assistance is the older one. The user generates an invitation, sends it, and the helper connects into their existing session. Both see the same screen, and control has to be offered and accepted explicitly. It is being retired but still appears in exam material and in older estates.

Quick Assist is the current one. The helper generates a code, the user types it in, and the user then chooses between screen sharing and full control. It works over the internet without firewall configuration, which is why it has largely replaced the older tool for ad hoc help.

The defining property of both: the user must be present and must consent, every time, and consent is per-session. That is not a limitation to work around; it is what makes them appropriate for helping someone with their own machine and their own data.

When to use which:

• The user is there and needs showing → assistance tool.
• The user is there and the job is unattended → agree a time, use Remote Desktop, and tell them their screen will lock.
• Nobody is there → Remote Desktop.
• The machine has no desktop at all → the next section.

SSH for the machines that have no desktop, and key-based access

SSH gives you a command line on a remote machine, encrypted, over a single port. It is how Linux and macOS machines are administered remotely, it is built into Windows as both client and optional server, and it is the right tool whenever there is no desktop to connect to or when a desktop would be wasteful.

The mechanics worth knowing:

• The client connects and verifies the host key. The first connection asks you to accept it; every later one checks it silently. A warning that the host key has changed is a real warning, not a formality — it means either the machine was rebuilt or you are not talking to the machine you think you are.
• Authentication is by password or by key pair. The private key stays on your machine, the public key goes into the remote account's authorised keys file, and nothing secret crosses the network.
• Key-based access is both more convenient and more secure, which is an unusual combination and the reason it is the norm. Keys can be protected with a passphrase, they cannot be guessed, and they can be revoked individually by deleting one line.

Two adjacent uses worth recognising: SSH can carry file transfers (SFTP/SCP), and it can tunnel another protocol over the encrypted connection — which is how a remote desktop session reaches a machine that does not expose one directly. That last technique is the professional answer to the exposure problem in the final section.

Third-party remote tools, and the consent step that is not optional

Third-party remote tools — the commercial support platforms — solve a genuine problem: they work through firewalls and network address translation without anyone configuring anything, because the machine connects out to the vendor's service and the technician meets it there.

What they offer beyond the built-in tools: unattended access to machines that are registered, file transfer, session recording, and a support queue.

The part that is not negotiable is consent. Attended sessions require the user to start the connection or accept it, and unattended access requires an agent installed with the owner's knowledge. Connecting to someone's machine without their knowledge is not a technical capability question; it is a conduct question, and the operational procedures objective at the end of this course treats it as one.

There is also a social engineering dimension worth stating explicitly, because it is examinable and it is real: the single most common technical-support scam works by persuading a victim to install exactly this kind of tool. That means two things for a technician. Never ask a user to install remote software in response to a call they did not initiate. And when a user reports that "support" asked them to install something, the correct assumption is fraud until established otherwise, and the response is the compromise procedure rather than reassurance.

Security: exposure to the internet, and why a remote port is not a remote plan

This is the part that turns a convenience into an incident.

Exposing a remote desktop port directly to the internet is one of the most reliably exploited configurations there is. It is scanned continuously, it is attacked by credential stuffing and brute force around the clock, and a successful login gives an attacker an interactive desktop on the machine. The same applies to an SSH port with password authentication and a weak password.

Changing the port number does not fix this. It reduces automated noise slightly and it is not a control — the port is found by scanning in minutes.

What actually works, in order of preference:

• A VPN. The remote service is not exposed at all; you join the network first and then connect. This is the standard answer and the one the exam wants.
• A remote access gateway designed for the purpose, which publishes the service with authentication in front of it.
• A third-party tool with outbound connections, which exposes nothing.
• SSH with key-only authentication, if a service must be exposed. Disable password authentication entirely and the brute-force problem disappears.

And regardless of route: multifactor authentication on the accounts, an account lockout policy, logging that someone reads, and access limited to the accounts that need it rather than to every administrator.

The sentence worth carrying out of this lesson: a port forward is not a remote access plan. It is the absence of one, and it is a decision a support technician is often the person making.