Remote access tools are the bread and butter of today’s support technician. For many remote access needs, traditional tools (bundled with the OS, provided by the OS vendor, etc.) are used: RDP, SSH clients/servers, Telnet, etc. Let's see how they compare with each other.
Telnet is obsolete and insecure, so it’s not widely used any more, being replaced by SSH.
It requires certain expertise to configure an SSH tunnel but it enables the necessary functionality (work with file system, send commands) and it’s popular due to its security and open architecture. Client and server applications that work over SSH are available for all major platforms, including Linux, Unix, MacOS and Windows. Putty is probably the most popular SSH client for Windows right now. Also, SSH is often the only way to communicate to mobile and embedded devices.
Yet SSH is not very convenient when it comes to working with a GUI-enabled OS. The protocol does not support sending of keyboard and mouse events and the transfer of the remote desktop image. That is why a proliferation of third-party remote access solutions exist today. Still, SSH is a very handy tool for certain usages and is much appreciated by the professionals.
RDP is a secure protocol initially developed for Windows, but is theoretically usable on such platforms as Mac and Linux.
It efficiently utilizes the available bandwidth, although not permitting nearly real-time responses that enable remote gaming, for example.
The main problem behind RDP usage is that it requires some configuration, and it does not working in certain network configurations. You’d be surprised to know how even an experienced computer user fails to set a few ticks on the Windows System Properties –> Remote screen for you to sign in.
The development of the VNC project was by far the most important event in the history of the remote access tools that exist today, including highly successful commercial solutions.
The VNC protocol allows controlling machines working on GUI-driven OSes (send keyboard and mouse events and receive remote machine screen updates). What’s more important, VNC source code is licensed under the GNU license. This has led to a vista of commercial products that rely on the protocol.
Standalone applications normally require installations or certain permissions on the system. Some even get detected as malware by certain AV software. Examples of standalone tools: TeamViewer, AMMYY, some VNC-based products.
Browser-based tools are a relatively new trend. Most often (though not always!) they rely on a Flash-based viewport and require login on the tool vendor website. Examples: SkyFex, DeskRoll, Guacamole.
Direct connection means that the data is transferred from one host to another without being processed or relayed by a third host. Obviously, direct connection eliminates as much bottlenecks as possible. Normally, it’s implemented in either of the two ways:
Client-server solutions may require configuration and elevated rights during installation but they are more likely to do data transfer directly.
P2P solutions are easier to install and they normally require no configuration. Still, in some cases they may fail to transfer data directly relying on the central server instead (if possible).
Now major remote access solution vendors are testing and offering cloud-based file storage as part of a remote access service. This feature allows storing the necessary files in one place and sending them to as many locations as you like. It’s very handy if you need to send from a fixed set of files to many locations. Also, it naturally fits with remote collaboration ideas. Currently, it’s being tested by the major players and it’s too early to talk whether it’s cost-effective or not.
Examples: LogMeIn's Cubby, Citrix ShareFile.
Can be implemented in several ways:
Sometimes you may want to brand the tool your service with your company style, logo, colors, links, etc. This option is usually offered with expensive solutions, although there are some exceptions out there. Examples: TeamViewer, SkyFex.