XWN740 X-Windows Configuring and Using Remote Access (Chapter 13: Pages 175-192)

XWN740

X-WindowsConfiguring and Using

Remote Access(Chapter 13: Pages 175-192)

Agenda

Remote Access: Purpose of Remote Access

Displaying on a Remote Server Remote Sessions

Query, broadcast, indirect

Challenges of Remote Access Network Bandwidth & Latency Access Control Privacy

X Windows & Hardware

Remote Access

As defined earlier in this course, X Windows is a portable, network-transparent window system.

The phrase network-transparent refers to the location-independence of the clients and server—the client may be on the same machine as the server or on machines spread all over the planet, as long as he has a network connection to the server...


Remote Access – Display Specification

Since X clients can connect to a display anywhere on the network, it is necessary to have some way of specifying the display to be used. This is done using a display specification (or displayspec).

A displayspec takes this form:

host:display[.screen]



Host The name or network address of the system running

the X server (eg. DNS, IP Address, unix, DecNET, IPX/SPX)

Display The Display number, greater to or equal to zero

(eg. :0, :1, :2 etc...)



Screen An optional screen number within the display; screens

are numbered at zero. For example, one monitor is used to control and set-up applications, and the second monitor displays live output to an audience such as a Wide Screen TV to broadcast an organization's events...


Remote Access – Display Specification - Example

You are currently using my_server in Canada and you want to run xclock application on other_server in Europe. The IP address of other_server is 175.34.56.1

On my_server, you must disable access control, or limit access controls (such as xhost + or

xhost +175.34.56.1) Then on my_server, issue command like:

xclock -display 175.34.56.1:0


Remote Access – Display Specification - Example

Note:

For this to work, you may need to check your firewall settings, both on your router/switch and on the host running the X server.

On a Linux system, iptables-L will show you the current firewall rules; you can configure the settings with your distribution's tools (such as lokkit or Yast) or use the iptables command.


Enabling Remote Sessions

Display managers—such as XDM, GDM, and KDM—manage local X displays, but are also capable of managing remote displays through a protocol called X Display Manager Control Protocol (XDMCP).

XDMCP enables a user to remotely log in to a server using a graphical authentication dialog. After the user has logged in, a normal session is started (including the window manager, desktop environment, and so forth), as though the user was using a local X server.


Enabling Remote Sessions

XDMCP uses both TCP and UDP on port 177. It is disabled by default in most distributions and must be enabled before remote session can be used; the procedure to enable it varies according to the display manager in use.

Refer to X Power Tools (Pages x - x)


Remote Access – Enabling Remote Sessions

There are 3 methods in which to run X Windows to access the session manager using XDMCP:

Query Efficient (in terms of bandwidth) connection

request to a specific host.Broadcast

Connection to first available host (useful for load-balancing).

Indirect Select host from a menu


Remote Access – Enabling Remote Sessions

Examples

Query X :0 -query 175.34.56.1

Broadcast X :0 -broadcast

Indirect X :0 -indirect 175.34.56.1


Challenges of Remote Access

There are three challenges that any X remote access solution must address; one affects performance, and the remaining two affect security:

Network Bandwidth and Latency Access Control Privacy


Network Bandwidth & Latency

Bandwidth refers to the overall network data-delivery rate; latency refers to the round-trip delay. X requires moderate network bandwidth and low latency to deliver an effective user interface.

SOLUTION: X Tunneling with SSH

Secure Shell ( SSH) provides a simple and effective way to run X clients on a remote machine, addressing all three challenges of remote access. This is by far the preferred approach to running remote X clients.


Tunneling with SSH

At its most basic level, SSH provides remote shell access, acting like a secure version of telnet. But SSH also provides tunneling capability, which creates a listening port on one end of the connection and forwards any TCP/IP connections through the encrypted channel to a designated port on the remote host (or any system directly reachable from the remote host). Going one step further, SSH provides an enhanced version of the tunneling facility specifically for X traffic.


Tunneling with SSH

Once you have connected to a remote system using SSH with X11 forwarding turned on, you can start X clients.

It's also possible to specify the name of the client directly on the SSH command line. For example, to run kcalc on other_server:

ssh -X [email protected] kcalc


Tunneling with SSH

"But wait—there's more!" SSH also has a compression feature, which is enabled with the -C option:

ssh -X -C [email protected] kcalc

Although this is a simple data-stream compression (like gzip), it provides at least as much benefit as LBX in most use cases.


Using Public Keys with SSH

SSH provides a simple way of starting a remote X client with a single command (Section 13.12). It's often convenient to place an SSH command in a .desktop file so that a menu option or icon will invoke a remote client automatically.

It's possible to configure SSH to use public key cryptography for authentication instead of passwords. This eliminates the password prompt altogether and makes remote client execution beautifully seamless. You will see this in next week's lab...


Passphrase Protection of SSH Keys

Using SSH without public key authentication results in a password request for each new SSH connection, but using SSH with public key authentication is only as secure as the ~/.ssh/id_rsa file. If that file is compromised—by a trojan program, account compromise, or even a stolen copy of a system backup—the accounts on other hosts will also be compromised. The challenge is balancing convenience against vulnerability.


Passphrase Protection of SSH Keys

SSH provides a solution to this problem too (of course!). Your private key file can be protected by a passphrase, and the ssh-agent program can be set up to request the passphrase only once per session, regardless of how many SSH connections are later established. If the private key file is stolen, it will be useless without the passphrase.

You will see this in next week's lab...

Documents

XWN740 X-Windows Configuring and Using Remote Access (Chapter 13: Pages 175-192)