Remote Access and Management

Why remote access

Most IT work today happens at a distance. A help desk technician takes over a user's screen to fix a printer setting; an administrator restarts a service on a server in a data center or the cloud; an employee works from home on a desktop PC in the office. In all three cases the technician needs to see or control a computer without sitting in front of it. The tools differ in what they give you (a full desktop, a shared screen, a command line) and in who starts the session (the user asking for help, or the administrator).

Remote access is also one of the most common ways attackers get in. An exposed login screen can be attacked from anywhere in the world, around the clock. Everything on this page therefore has a security side, summarized in Securing remote access.

Remote Desktop

Remote Desktop Protocol (RDP) is Microsoft's protocol for working on a Windows computer's desktop over the network. The remote computer runs the session; only the screen image travels to you, and your keyboard and mouse input travels back. RDP listens on TCP port 3389 (and UDP 3389 for better performance), and encrypts the session with Transport Layer Security (TLS).

Host and client

• Host (the computer you connect to): Windows 11 Pro, Enterprise and Education, and Windows Server. Windows Home cannot accept Remote Desktop connections. Turn it on under Settings → System → Remote Desktop; only administrators and members of the Remote Desktop Users group may connect.
• Client: every Windows edition, including Home, has Remote Desktop Connection (mstsc). Microsoft also offers the Windows App for Windows, macOS, iOS and Android.

On a Windows client, a Remote Desktop session locks the local screen: the user at the computer is signed out of view while you work. For helping a user who is looking at the same screen, use Quick Assist instead.

mstsc /v:pc-042.corp.example.com

Before blaming credentials, check whether the port can be reached at all. In PowerShell:

Test-NetConnection -ComputerName pc-042.corp.example.com -Port 3389

ComputerName     : pc-042.corp.example.com
RemoteAddress    : 10.20.4.42
RemotePort       : 3389
InterfaceAlias   : Ethernet
SourceAddress    : 10.20.1.15
TcpTestSucceeded : True

False points to the network or a firewall, or to Remote Desktop being turned off on the host — not to a wrong password.

Network Level Authentication

Network Level Authentication (NLA) makes the user authenticate before the host builds a full desktop session and shows a sign-in screen. Without NLA, anyone who can reach port 3389 gets a session started on the host, which costs resources and gives attackers more code to attack. NLA is on by default on current Windows versions; leave it on.

Never expose RDP to the internet

Port 3389 open to the internet is found by automated scanners within hours, and then receives a constant stream of password guessing. Exposed RDP has long been one of the most common entry points for ransomware. Reach RDP through a virtual private network (VPN), through a Remote Desktop Gateway, which wraps RDP in Hypertext Transfer Protocol Secure (HTTPS) on port 443 and can require multi-factor authentication, or through a jump server — and never by forwarding port 3389 on the router.

Helping users: Quick Assist and remote support tools

Help desk work is usually attended: the user is at the computer, sees what the technician does, and has to agree to the session. That consent is both a courtesy and a security control.

Quick Assist and Remote Assistance

Quick Assist is built into Windows 10 and 11. The helper signs in with a Microsoft account and gets a short security code; the user opens Quick Assist, enters the code and must approve sharing the screen. The helper can then view the screen or, if the user approves that too, take control. Either side can end the session at any time. The connection goes through Microsoft's cloud service over HTTPS, so no inbound firewall ports are needed.

Because Quick Assist needs no installation, scammers use it too: a user should only enter a code given by a technician they contacted themselves. Many organizations use an approved tool with verified technician identities instead.

Windows Remote Assistance (msra) is the older tool with the same idea, based on an invitation file or Easy Connect. It still exists, but Quick Assist has replaced it for most help desk work.

Third-party remote support tools

Many organizations use commercial tools instead. They fall into a few categories:

• Attended remote support: the user runs a small program or opens a web page and reads a session code to the technician.
• Unattended access: an agent installed on the computer lets authorized technicians connect without a user present, for servers or after-hours work.
• Screen sharing in video-conferencing software: often good enough to guide a user, and sometimes allows giving control.
• File transfer tools: moving logs or installers to and from the computer during the session.

Choose one approved tool, keep it updated, protect the technician accounts with multi-factor authentication, and log every session. A remote support tool that nobody in IT manages is a door nobody is watching.

Tech support scams

Criminals use exactly these tools. A caller claims to be from Microsoft, the bank or "the IT department", says the computer is infected, and asks the user to install a remote support program or read out a code. Once connected, they install malware, steal data or demand payment. This is social engineering: the software is legitimate, the person is not.

SSH

SSH (Secure Shell) gives an encrypted command-line session on a remote computer, on TCP port 22. It is the standard way to manage Linux servers and network devices, and it replaced Telnet (TCP 23), which sent everything, including passwords, as clear text. SSH also copies files securely (scp, sftp) and can tunnel other protocols. Linux, macOS and Windows 10 and 11 all include the OpenSSH client; Windows can also run an OpenSSH server as an optional feature.

ssh ana@srv01.example.com

The authenticity of host 'srv01.example.com (192.0.2.10)' can't be established.
ED25519 key fingerprint is SHA256:Xk3vQ8Lr2mN6pT0yWb5cJ9dF1gH4sA7eK2uR8zV3qYo.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

On the first connection, SSH shows the server's host key fingerprint. Compare it with the fingerprint the server's administrator published before typing yes: it is how you know you reached the real server and not an impostor. SSH remembers the key in ~/.ssh/known_hosts and warns loudly if it ever changes.

Key-based authentication

SSH can authenticate with a password or with a key pair. The private key stays on your computer, protected by a passphrase; the public key is copied to the server. At login the server challenges your client to prove it holds the private key, and the key itself never crosses the network. Keys cannot be guessed the way passwords can, so a server that accepts only keys is immune to password guessing.

ssh-keygen -t ed25519 -C "ana@laptop"
ssh-copy-id ana@srv01.example.com

ssh-keygen creates the pair (by default in ~/.ssh/id_ed25519 and id_ed25519.pub); ssh-copy-id adds the public key to ~/.ssh/authorized_keys on the server. Windows has no ssh-copy-id; there you append the contents of the .pub file to that file on the server. Once keys work, the administrator can turn off password logins and direct root logins in the server's configuration. Put the settings in a file under /etc/ssh/sshd_config.d/ (or check that no file there overrides them — sshd keeps the first value it reads, and cloud images often ship a file that sets PasswordAuthentication yes):

PasswordAuthentication no
PermitRootLogin no

Check the syntax with sudo sshd -t, then reload the service (sudo systemctl reload ssh on Ubuntu and Debian, sudo systemctl reload sshd on RHEL), and confirm the settings sshd actually uses:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauth|permitroot'

permitrootlogin no
passwordauthentication no

VNC

VNC (Virtual Network Computing) shares a graphical desktop using the Remote Framebuffer (RFB) protocol, usually on TCP port 5900 (5901 for display 1, and so on). Its strength is that it is platform-independent: servers and viewers exist for Windows, macOS, Linux and more, and the built-in Screen Sharing of macOS is VNC-compatible. VNC shows the same screen the local user sees, unlike RDP, which starts its own session.

Its weakness is security. The original VNC authentication uses a password of at most eight characters and does not encrypt the session itself; some current products add encryption and proper authentication, others do not. Treat VNC as unencrypted unless the product documents otherwise, and run it only through an SSH tunnel or a VPN.

WinRM and SPICE

Windows Remote Management (WinRM) lets administrators run PowerShell commands and scripts on remote Windows computers, over HTTP on TCP port 5985 or HTTPS on TCP port 5986; allow it only from the management network. The Simple Protocol for Independent Computing Environments (SPICE) is used for the remote consoles of virtual machines.

Remote monitoring and management

Remote monitoring and management (RMM) software manages many computers from one console through an agent installed on each of them. Managed service providers (MSPs), which look after the IT of many small customers, depend on it. A typical RMM platform:

• monitors health (disk space, failed services, backup results) and raises alerts or tickets;
• deploys patches and software, and runs scripts on one computer or thousands;
• offers remote control and a remote command line;
• keeps an inventory of hardware and software.

The agent connects outbound to the RMM service over HTTPS, so no inbound ports have to be opened. The flip side: whoever controls the RMM console controls every managed computer at once. Attackers have used compromised RMM platforms to spread ransomware to many customers in one go, as in the 2021 attack through Kaseya VSA. Protect RMM accounts with strong multi-factor authentication and the tightest privileges you can, and patch the RMM server or agent with priority.

Securing remote access

VPNs and gateways

The first rule: remote access services should not face the internet directly. A VPN puts the remote user's device logically on the internal network through an encrypted tunnel, after which RDP or SSH is used as if in the office. A gateway (such as Remote Desktop Gateway) accepts connections on one hardened, well-monitored entry point and forwards only permitted sessions. Either way, the login that the internet can see is one that enforces multi-factor authentication.

Jump servers

A jump server (also bastion host) is a hardened computer that administrators must connect to first, and from which they continue to the servers they manage. The servers accept administrative connections only from the jump server. That gives one place to enforce multi-factor authentication, one place to log and record every session, and one place to patch with priority — instead of dozens of servers each open to many workstations.

MFA and the other controls

Multi-factor authentication (MFA) requires two or more different kinds of proof: something you know (a password or PIN), something you have (an authenticator app, a hardware security key, a smart card) and something you are (a fingerprint or face). A stolen or guessed password alone is then not enough. For remote access it is the single most effective control. The others complete the picture:

• Least privilege: give remote access only to the people and computers that need it, and use separate administrator accounts instead of everyday accounts with admin rights.
• Account lockout: lock or slow down an account after a number of failed logins, to stop password guessing.
• Logging: record who connected, from where and when, and review failed logins. In Windows, successful and failed logons appear in the Security log (events 4624 and 4625); an RDP logon is event 4624 with logon type 10 (RemoteInteractive).
• Patching: remote access software and the systems exposing it get security updates first; RDP, VPN and remote support products have all had critical vulnerabilities.
• Restrict by source: firewall rules that allow management ports only from the VPN range or the jump server.

That last point is easy to audit. The program below checks a list of inbound firewall rules for remote access ports that are open to any source address:

REMOTE_ACCESS_PORTS = {22: "SSH", 23: "Telnet", 3389: "RDP", 5900: "VNC"}

inbound_rules = [
    ("web server", "any", 443),
    ("office PCs", "any", 3389),
    ("linux servers", "10.20.9.0/24", 22),
    ("old kiosk", "any", 5900),
    ("switches", "10.20.9.5/32", 23),
    ("file server", "10.20.9.5/32", 3389),
]

for name, source, port in inbound_rules:
    service = REMOTE_ACCESS_PORTS.get(port)
    if service is None:
        continue
    if source == "any":
        print(f"RISK  {name}: {service} (TCP {port}) open to any source")
    elif service == "Telnet":
        print(f"WARN  {name}: Telnet sends passwords in clear text; use SSH")
    else:
        print(f"ok    {name}: {service} (TCP {port}) only from {source}")

RISK  office PCs: RDP (TCP 3389) open to any source
ok    linux servers: SSH (TCP 22) only from 10.20.9.0/24
RISK  old kiosk: VNC (TCP 5900) open to any source
WARN  switches: Telnet sends passwords in clear text; use SSH
ok    file server: RDP (TCP 3389) only from 10.20.9.5/32

Remote access methods compared