1. XWN740 X-Windows Configuring and Using Remote Access
(Chapter 13: Pages )

2. 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

3. 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...

4. X Windows & Hardware 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]

5. X Windows & Hardware Remote Access – Display Specification 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...)

6. X Windows & Hardware Remote Access – Display Specification 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...

7. X Windows & Hardware 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
On my_server, you must disable access control, or limit access controls (such as xhost or xhost )
Then on my_server, issue command like: xclock -display :0

8. X Windows & Hardware 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.

9. X Windows & Hardware 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.

10. X Windows & Hardware 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)

11. X Windows & Hardware 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

12. X Windows & Hardware Remote Access – Enabling Remote Sessions Examples
Query
X :0 -query
Broadcast
X :0 -broadcast
Indirect
X :0 -indirect

13. X Windows & Hardware 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

14. X Windows & Hardware 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.

15. X Windows & Hardware 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.

16. X Windows & Hardware 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 kcalc

17. X Windows & Hardware Tunneling with SSH
"But wait—there's more!" SSH also has a compression feature, which is enabled with the -C option:
ssh -X -C kcalc
Although this is a simple data-stream compression (like gzip), it provides at least as much benefit as LBX in most use cases.

18. X Windows & Hardware 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...

19. X Windows & Hardware 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.

20. X Windows & Hardware 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...