Transcript X Windows & Hardware Remote Access

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 datadelivery 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 [email protected] 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 [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.
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...