Section 11.5. I Need to Run an X Application Remotely

11.5. I Need to Run an X Application Remotely

Sometimes you need to run a GUI application but can't get to your computer. You may want to support users who need remote access to their applications.

I'll assume that you've already set up Secure Shell (SSH) or VNC clients for these users. In this annoyance, I'll show you how you can configure secure remote access to your GUI applications. While you can use VNC, SSH is preferred, as it provides strong encryption, making it more difficult for a cracker to track your keystrokes. An SSH configuration means that you're networking only the GUI application that you happen to be running remotely, as opposed to a whole GUI desktop environment.

There are relatively secure versions of VNC available; you can even tunnel VNC through an SSH connection. For more information on the wide variety of VNC servers and clients, Wikipedia provides an excellent starting point at http://en.wikipedia.org/wiki/VNC. If you don't like VNC, explore the increasingly popular FreeNX (which uses SSH) at http://freenx.berlios.de/.

If you absolutely need remote access for GUI applications, keep it behind a firewall. If at all possible, don't open the firewall to external clients on the SSH ports. If you do, use the directives described in the following sections (and the previous annoyance) to minimize your risks.

11.5.1. Configuring the SSH Server for X Access

The configuration file for the SSH server is /etc/ssh/sshd_config. While it offers a substantial number of directives, most of the defaults configured on our target distributions don't need to be changed for SSH to work. However, these defaults may not be secure. Depending on your distribution, you may need to make a few changes. I suggest you pay particular attention to the following directives:

X11Forwarding yes

As the object of this annoyance is how to safely configure remote access of GUI applications, I assume you'll use this directive to enable remote access.

Protocol 2

Specifies the use of the SSH2 protocol, which is currently being maintained and updated for any security problems. Without this directive, the SSH server can also take logins from SSH1 clients, which are less secure.

ListenAddress

Allows you to specify the IP address of the network card to take SSH connections, such as ListenAddress 192.168.0.12. Assumes you have more than one network card on this computer.

LoginGraceTime

Helps thwart crackers who try to break into an account with different passwords. The default is 120 seconds, after which no additional password entries are allowed. I would set a shorter period, such as LoginGraceTime 30.

PermitRootLogin no

The default is yes. In my opinion, you should never permit logins by the root user. Even if encrypted, root logins are a risk. If the login is intercepted, the root password may be eventually decrypted. In contrast, if you use the su or sudo commands after logging in via SSH, it's much more difficult for a cracker to determine which bits contain the root password.

Alternatively, you can create encryption keys as described in the previous annoyance. Once configured, SSH login passwords don't get sent over the network.

AllowUsers

By default, all users are allowed to log in via SSH. It's best to limit this as much as possible. You can limit logins by users, or even by users on specific systems. For example, if you wanted to limit SSH access to two users, you might use one of the following directives:

 AllowUsers michael donna AllowUsers [e-mail] [e-mail] 

In the second directive, SSH logins to the local accounts for michael and donna are allowed from the remote debian.example.com system.

After saving changes to the SSH server configuration file, you'll need to restart the associated daemon. The name of the daemon may vary slightly by distribution; you can use the following command for Red Hat/Fedora and SUSE Linux:

 /etc/init.d/sshd restart 

The appropriate command on Debian Linux is slightly different:

 /etc/init.d/ssh restart 

11.5.2. Configuring the SSH Client for X Access

There are three ways to configure the SSH client to support networking of GUI tools and applications:

• Directly, via switches and options to the ssh connection command

• For all users on a client, via the /etc/ssh/ssh_config file

• For a single user on a client, via the ~/.ssh/config file

By default, any authorized user can log in to an SSH server, specifying access to GUI applications with the -X switch, e.g.:

 ssh -X [e-mail] 

But GUI access may not be secure. The most secure approach is to limit X access for all users on a client and then enable it for only the desired users. To do so, open /etc/ssh/ssh_config and set the following directives:

ForwardX11Trusted no

The default for this directive varies by distribution. This setting minimizes risks to other clients.

ForwardX11 no

Although this should be disabled by default on all Linux distributions, it doesn't hurt to make sure.

Next, on the ~/.ssh/config file for the user that you want to authorize, include:

ForwardX11 yes

This directive supersedes any default settings in the /etc/ssh/ssh_config file, and allows remote GUI access to the applications of that user's choice.

11.5.3. Remote SSH Access to GUI Applications

Once configured, you can access remote GUI applications through the command line. To this end, you'll need to know the text commands that start GUI applications, such as /usr/bin/oowriter. Unless you're running a network with gigabit-level speeds, expect a bit of a delay as the application opens (and as it runs remotely on your workstation).