XWN740 X-Windows Configuring 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...

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]

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

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

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

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.

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.

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)

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

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

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

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.

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.

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 username@175.34.56.1 kcalc

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 username@175.34.56.1 kcalc Although this is a simple data-stream compression (like gzip), it provides at least as much benefit as LBX in most use cases.

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

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.

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