Remote Access: How to make “Can you just do it for me?” easy

Have you ever been explaining something to someone about what to do on their computer to fix an issue and you wish you could just be there to do it for them? 

Or more likely, have you ever been on the phone with tech support being told to do something and it just gets way too complicated and wished they could just be there and do it for you. 

This blog is a brief overview of Remote Access Technology, we’re going to cover Remote Access Tools (RATs) mostly from a practical standpoint. We will also cover the advantages of using these tools.

 There will be some academic and historical context given as well about the development of these tools and the origins of remote access. Finally we will address modern tools, and the challenges presented by different platform compatibility and a practical solution to cross platform remote access. 

Advantages of Remote Access Tools and When to use Remote Access:

The most common tool used by technicians to diagnose and fix server issues is remote access. 

Remote Access has several advantages:

• No transport to site
• Immediate support available
• Escalation to different techs is immediate

Of course all of these advantages are just an expansion of the concept that a technician doesn’t need to travel to the site to perform the repair. 

The main disadvantage of remote access is complexity of setup. Allowing access to a remote server requires a level of trust in the technician and software.

When not to use Remote Access

• When issues are unlikely to be software related
• Issues that block network connectivity
• PC won’t boot and no display issues

Basic overview of network protocols and protocols used in remote access: 

The two main protocols historically used to remotely access a PC are TCP and UDP. 

TCP: Involved numerous connection managements like Real Time Streaming, Clear To Send, and Synchronize/Acknowledge to help ensure that data packets are efficiently sent and received. 

UDP: is referred to in most textbooks as a “Firehose” of information. It’s like two people yelling at each other across the room. The parties tend to mishear each other but it’s often the fastest way of communicating between two parties. 

History of Remote Access:

Remote Access was performed on a conceptual level by Stanford University in 1969 but it wasn’t until 1987 that remote access protocols were being used by actual service techs to complete field work on PCs using MS DOS. These early tests involved code that would eventually be identified as the Telnet protocol. 

Computers and people capable of using them were so rare that Telnet was established as a protocol even though it lacked any sort of security or authentication. To connect and make changes to a computer was as simple as calling the right number to be given command line level access to a machine. Telnet would eventually be updated to include those protocols but being able to use the protocol without authentication or encryption would cause the eventual replacement of Telnet by Secure Shell because widespread malware would scan computers on the internet all day simply looking for older or improperly configured servers to take over and exploit. 

There was a really popular film about hacking from the 80s called War Games that features a high school hacker gaining remote access to a pentagon AI that controls the US nuclear arsenal. This hack was only remotely believable due to telnet’s well known vulnerabilities.

Secure Shell Protocol:

Secure Shell is often abbreviated to SSH. It includes all the functionality of Telnet but is secure. It’s not possible to configure SSH to work without authentication. SSH is cryptographic by design. All commands except the initial handshake are encrypted and thus not vulnerable to Man in the Middle Attacks and Fingerprinting passwords. 

Fast Forward to Today:

SSH, like IP/TCP has proven a robust and expandable protocol still in use today. SSH is included by default in Linux, Mac, and Windows Operating Systems since the release of Windows 10. Windows operating systems before Windows 10 can have SSH installed and can also use PuTTY. Ironically today’s lagger was yesterday’s innovator. 

Even though the very first Remote Access services were performed on Windows; they were the last operating system to include modern remote access protocols. 

If you are on a limited budget, SSH is proprietary, meaning its access is restricted and can sometimes come at a cost to the user. OpenSSH is an open source protocol developed in 1999 to mimic the function of SSH without the proprietary limitations. 

Practical Challenges in modern Remote Access and why Remote Access Tech is controversial:

The most challenging step for a technician attempting to access a clients PC or server is establishing the initial connection and authentication. Even with expert phone support it can be challenging to prepare a machine because of the built in security around it. 

It can also be challenging because of the modern proliferation of scams, some of which use this technology so the operating system will have many prompts warning the user to not allow access unless they are certain about trusting the technician. 

Connecting to different types of Machines and Chrome Remote Desktop as a solution:

I started doing research for this subject and found that each type of protocol built into the operating system was needlessly complicated and required multiple steps to prepare the machine and limits on the connecting machine. 

For example, guess which operating system I have to be using the remote to connect to a mac? Anyone?

Since this is a practical blog I’d like to show you what I’m actually using at job sites when I’m given the leeway to divert from documentation. Personally I’ve been using Chrome Remote Desktop. It’s a Chrome Extension built by Google that is free. 

Chrome is already used by 65% of all users and it’s cross compatible with multiple operating systems including phones and tablets. If you only want to take away one thing today, it’s that learning to use this program is an efficient use of your time as a technician.

A key shortcoming of using this program is privacy. For HIPPA, military, and even some big corporate uses Chrome Remote Desktop does not meet the privacy guidelines required by most organizations. If you are doing a job for a company of this size it is very likely that you will be told exactly what programs to use to connect anyways and will not have a choice. 

Remote Access is the first tool that should be used when remote troubleshooting hardware and software issues due to its cost saving and time saving.