Definitive Linux Remote System Access Guide


General overview

We’re sure that many of you have been away from our home computers at a time when we needed access to a certain file or desktop program. Many companies have proprietary solutions (like GoToMyPC) that allow you to remotely access files on your home computer while you are away from it. While this service has a $19.95/month licensing fee (per computer, no less), there are alternatives that provide similar functionality on the Linux platform for free. Many of these free solutions are very versatile and are useful in a wide variety of situations. We show you how to master remote system access on your open-source machine.

Be Prepared

Before you can use the following solutions, you must become familiar with the concept of port forwarding. Your computer transfers data through a wide assortment of virtual ports. Each port is numbered and is dedicated to a specific purpose. (email usually funnels through port 25 while web content goes through port 80, for instance) For security reasons, your router's firewall is configured to block incoming traffic on most ports by default. If this were not the case, any person or program (malicious or not) would have access to your computer from the internet.

To use a remote access solution, you must configure your router to accept incoming connections on the port it uses. Most routers have a web-based interface to make this process easier. Typing  or  (the default gateway address, depending on your brand and model of router) into your web browser will probably allow you to access your router's settings. For specific instructions on how to enable port forwarding, check your router documentation.

When you set up port forwarding for a specific protocol, you are essentially configuring your router to send all incoming data received on that port to a specific computer on your network. This computer is essentially a gateway (no connection to the Gateway brand name). Once you have access to the gateway system, reaching the rest of the network is trivial.

Keep in mind that each open port is a potential security vulnerability since it provides an additional vector for an attacker to exploit. For this reason, only enable port forwarding for services that you actually need and expect to use often. Furthermore, your ISP may block incoming connections on some ports at a higher level than your router. The rationale behind that is that your ISP doesn't want you to run certain services (like a web server) over your consumer-grade internet connection, especially if they are selling business-grade connections with that functionality for more money. In such a scenario, your only options are to negotiate with your ISP to have them open the ports you need (they may allow only one or two, so choose wisely) or find another ISP.

Secure Shell

Many Linux users are familiar with the shell (sometimes referred to as a terminal or console). This command-line interface allows you to quickly execute commands or create shell scripts to automate certain tasks. Linux has a remote shell capability called Secure Shell (SSH). This protocol has practically replaced Telnet, and is used for the same purpose but with an additional security benefit.

When you initiate a SSH connection, a secure encrypted “tunnel” is created between your computer and a remote computer, and you effectively take control of the remote machine. Any commands you type on your local machine get forwarded to and executed on the remote machine. With SSH, you can even run GUI applications. (the output and interface will appear on your screen instead of that of the remote machine) SSH has a companion program called SCP that allows you to send files back and forth through an encrypted tunnel.

Almost all Linux and BSD distributions have a SSH client built in. (To learn how to use SSH, refer to the ssh manual file by running man ssh) Many graphical frontends exist for SSH/SCP, most notably Konqueror and Nautilus. To get SCP functionality on Windows, you need WinSCP .

Back in college, I used SSH on my laptop every day on the university's wireless LAN to interact with my computer back at home. I would use my home computer as a web proxy and send files back and forth with SCP. The college wireless network was very slow, but since SSH uses so little bandwidth I seldom experienced any slowdown except when I was tunneling GUI applications from my home computer.  However, such slowdown rarely happens over a wired Ethernet connection or a fast LAN, even with GUI applications.

Our favorite way of using SSH has always been through the native Linux shell-- Windows users don't have this option. If you want to SSH into a remote Linux or BSD machine from Windows, you will need a program called PuTTY .  While PuTTY is fine for text-only programs, a drawback of Windows is that it does not allow GUI applications to be sent through the tunnel due to the fact that Windows does not use Xorg as its graphic engine like most Linux distributions do.

Some people set up Xorg to run on Cygwin to get around this, but we’ve found it much easier to simply virtualize a lightweight Linux distribution like DamnSmallLinux and run SSH through it. Since the virtualized operating system has a fully functional Xorg environment, GUI applications work just fine through the SSH tunnel.

To enable SSH functionality on a machine, you need to install OpenSSH server and have it run at boot. (For Ubuntu and Debian, all you have to do is run sudo apt-get install ssh and configure your router to get SSH up and running) Your router likely has a preset option for enabling SSH. If not, you must configure your router to allow incoming TCP and UDP packages on port 22. For maximum security, you should disable root logins (and have a strong, well-secured root password) and enable public-key certificate authentication in addition to a password. You should share the public certificate and the login password only with people you can trust.

Virtual Network Computing

Virtual Network Computing (VNC) is another remote access method. VNC is platform agnostic, so no kludgy workarounds are required as they are for SSH; a native Windows VNC client will interact just fine with a Linux system and vice versa. VNC offers more precise control over a remote system than SSH; you can see a near real-time representation of the remote computer's screen and you can sometimes control the remote computer down to the act of moving the pointer and entering text. In a practical sense, VNC is the opposite of SSH in that VNC allows you to project your control into the remote system instead of projecting control of the remote system into your computer.

Implementing VNC is fairly straightforward. If you are using the GNOME Desktop Environment, there is a built-in VNC client called Vinagre . (After installing Vinagre, run vinagre %U)  To change the VNC settings for your local computer, run vino-preferences.  KDE features a VNC program called Krdc that is similar to Vinagre, but offers more configuration options.

To allow VNC access from outside of your network, set up forwarding on port 5900. For adequate security, you should configure your VNC server to force remote users to ask permission before any connection is made in addition to requiring a password. To limit what remote users may do on your computer through VNC, you should disable remote control. For maximum security, you should block port 5900 on your router except for the times when you actually need to access your system through VNC.

For all the control it offers, VNC is not without its drawbacks. Maintaining the link requires considerable bandwidth, (much more than SSH) making VNC not suitable for very slow connections or busy networks. Also, remote users may limit what can be done over a VNC connection by disabling remote control and requiring permission to establish a connection, so you may only be able to watch but not control the remote system even if the remote user lets you in. (in contrast, SSH with root access is essentially omnipotent) Lastly, VNC is not suitable for stealth connections.

Even though you can see everything on the remote computer's screen, the VNC server will usually announce the connection to the remote user. SSH is essentially invisible unless the remote user is actively looking for unwanted connections, so a SSH connection may easily go unnoticed unless you do something to attract the remote user's attention. Once you have a SSH connection established, there are plenty of ways to see what the remote system is doing without requiring a real-time view of the screen.

Bottom Line

While remote access programs may be incredibly useful, they can also be major security vulnerabilities if used improperly. Adequate security measures are built into each of these tools, but it is up to you to implement them. Furthermore, each one of these remote access tools has specific instances and purposes for which it is most effective. VNC is ideal for instruction and collaboration over a fast network where real-time access is required, but is less than ideal for behind-the-scenes administration. In the same way, SSH is extremely powerful for remote administrative tasks, but requires more skill to use and does not allow for true interaction. To be an effective remote administrator, you must know which tool to use in any given situation.

Around the web