Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
GetNetWise: You
e One Click Away

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 356 guest(s) and 3 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

HOWTO Home

Current HOWTO: Remote X Apps mini-HOWTO


Remote X Apps mini-HOWTO: Telling the Server Next Previous Contents

6. Telling the Server

The server will not accept connections from just anywhere. You don't want everyone to be able to display windows on your screen. Or read what you type -- remember that your keyboard is part of your display!

Too few people seem to realise that allowing access to your display poses a security risk. Someone with access to your display can read and write your screens, read your keystrokes, and read your mouse actions.

Most servers know two ways of authenticating connections to it: the host list mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, the secure shell, that can forward X connections.

Notice that some X servers (from XFree86) can be configured not to listen on the usual TCP port with the -nolisten tcp argument. Notably the default configuration of Debian GNU/Linux is to disable the X server listening on the TCP port. If you wish to use remote X on a Debian system, you should re-enable this by altering the way the X server is started. Look at /etc/X11/xinit/xserverrc for a start.

6.1 Xhost

Xhost allows access based on hostnames. The server maintains a list of hosts which are allowed to connect to it. It can also disable host checking entirely. Beware: this means no checks are done, so every host may connect!

You can control the server's host list with the xhost program. To use this mechanism in the previous example, do:

light$ xhost +dark.matt.er

This allows all connections from host dark.matt.er. As soon as your X client has made its connection and displays a window, for safety, revoke permissions for more connections with:

light$ xhost -dark.matt.er

You can disable host checking with:

light$ xhost +

This disables host access checking and thus allows everyone to connect. You should never do this on a network on which you don't trust all users (such as Internet). You can re-enable host checking with:

light$ xhost -

xhost - by itself does not remove all hosts from the access list (that would be quite useless - you wouldn't be able to connect from anywhere, not even your local host).

Xhost is a very insecure mechanism. It does not distinguish between different users on the remote host. Also, hostnames (addresses actually) can be spoofed. This is bad if you're on an untrusted network (for instance already with dialup PPP access to Internet).

6.2 Xauth

Xauth allows access to anyone who knows the right secret. Such a secret is called an authorization record, or a magic cookie. This authorization scheme is formally called MIT-MAGIC-COOKIE-1.

The cookies for different displays are stored together in ~/.Xauthority. Your ~/.Xauthority must be inaccessible for group/other users. The xauth program manages these cookies, hence the nickname xauth for the scheme.

You can specify a different cookie file with the XAUTHORITY environment variable, but you will rarely need this. If you're not sure which cookie file your xauth is using, do an xauth -v, and it will tell you.

On starting a session, the server reads a cookie from the file that is indicated by the -auth argument. After that, the server only allows connections from clients that know the same cookie. When the cookie in ~/.Xauthority changes, the server will not pick up the change.

Newer servers can generate cookies on the fly for clients that ask for it. Cookies are still kept inside the server though; they don't end up in ~/.Xauthority unless a client puts them there. According to David Wiggins:

A further wrinkle was added in X11R6.3 that you may be interested in. Via the new SECURITY extension, the X server itself can generate and return new cookies on the fly. Furthermore, the cookies can be designated ``untrusted'' so that applications making connections with such cookies will be restricted in their operation. For example, they won't be able to steal keyboard/mouse input, or window contents, from other trusted clients. There is a new ``generate'' subcommand to xauth to make this facility at least possible to use, if not easy.

Xauth has a clear security advantage over xhost. You can limit access to specific users on specific computers. It does not suffer from spoofed addresses as xhost does. And if you want to, you can still use xhost next to it to allow connections.

Making the Cookie

If you want to use xauth, you must start the X server with the -auth authfile argument. If you use the startx script, that's the right place to do it. Create the authorization record as below in your startx script.

Excerpt from /usr/X11R6/bin/startx:

mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

Mcookie is a tiny program in the util-linux package, primary site ftp://ftp.math.uio.no/pub/linux/. Alternatively, you can use md5sum to massage some random data (from, for instance, /dev/urandom or ps -axl) into cookie format:

dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

If you can't edit the startx script (because you aren't root), get your system administrator to set up startx properly, or let him set up xdm instead. If he can't or won't, you can make a ~/.xserverrc script. If you have this script, it is run by xinit instead of the real X server. Then you can start the real X server from this script with the proper arguments. To do so, have your ~/.xserverrc use the magic cookie line above to create a cookie and then exec the real X server:

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

If you use xdm to manage your X sessions, you can use xauth easily. Define the DisplayManager.authDir resource in /etc/X11/xdm/xdm-config. Xdm will pass the -auth argument to the X server when it starts. When you then log in under xdm, xdm puts the cookie in your ~/.Xauthority for you. See xdm(1) for more information. For instance, my /etc/X11/xdm/xdm-config has the following line in it:

DisplayManager.authDir: /var/lib/xdm

Transporting the Cookie

Now that you have started your X session on the server host light.uni.verse and have your cookie in ~/.Xauthority, you will have to transfer the cookie to the client host, dark.matt.er. There are several ways to do this.

Shared Home Directories

The easiest is when your home directories on light and dark are shared. The ~/.Xauthority files are the same, so the cookie is transported instantaneously. However, there's a catch: when you put a cookie for :0 in ~/.Xauthority, dark will think it's a cookie for itself instead of for light. You must use an explicit host name when you create the cookie; you can't leave it out. You can install the same cookie for both :0 and light:0 with this little piece of sed wizardry:

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

By the Remote Shell, rsh

If the home directories aren't shared, you can transport the cookie by means of rsh, the remote shell:

light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -

  1. Extract the cookie from your local ~/.Xauthority (xauth nlist :0).
  2. Transfer it to dark.matt.er (| rsh dark.matt.er).
  3. Put it in the ~/.Xauthority there (xauth nmerge -).

Notice the use of ${HOST}. You need to transport the cookie that is explicitly associated with the local host. A remote X application would interpret a display value of :0 as referring to the remote machine, which is not what you want!

Manually, by Telnet

It's possible that rsh doesn't work for you. Besides that, rsh also has a security drawback (spoofed host names again, if I remember correctly). If you can't or don't want to use rsh, you can also transfer the cookie manually, like:

light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Password:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth
Using authority file /home/zweije/.Xauthority
xauth> add light.uni.verse:0 . 076aaecfd370fd2af6bb9f5550b26926
xauth> exit
Writing authority file /home/zweije/.Xauthority
dark% xfig &
[15332]
dark% logout
light$

See also rsh(1) and xauth(1x) for more information.

Automating the Telnet Way

It may be possible to piggyback the cookie on the TERM or DISPLAY variable when you do a telnet to the remote host. This would go the same way as piggybacking the DISPLAY variable on the TERM variable. See section 5: Telling the Client. You're on own here from my point of view, but I'm interested if anyone can confirm or deny this.

Notice, however, that environment variables can be observed by others on some unices, and you won't be able to prevent the cookie in $TERM from showing up if people are looking for it.

Using the Cookie

An X application on dark.matt.er, such as xfig above, will automatically look in ~/.Xauthority there for the cookie to authenticate itself with.

There's a little wrinkle when using localhost:D. X client applications translate localhost:D into host/unix:D for the purpose of cookie retrieval. Effectively, this means that a cookie for localhost:D in your ~/.Xauthority has no effect.

If you think about it, it's only logical. The interpretation of localhost depends entirely on the machine on which it's interpreted. It would give a horrible mess when you have a shared home directory, such as through NFS, with several hosts all interfering with each other's cookies.

6.3 Ssh

Authority records are transmitted over the network with no encryption. If you're even worried someone might snoop on your connections, use ssh, the secure shell. It can do X forwarding over encrypted connections.

To turn on X forwarding over ssh, use the command line switch -X or write the following in your local ssh configuration file:

Host remote.host.name
    ForwardX11 yes

The ssh server (sshd) at the remote end automatically sets DISPLAY to point to its end of the X forwarding tunnel. The remote tunnel end gets its own cookie; the remote ssh server generates it for you and puts it in ~/.Xauthority there. So, X authorisation with ssh is fully automatic.

By the way, ssh is great in other ways too. It's a good structural improvement to your system. For more information, visit http://www.ssh.org/, the ssh home page.

Who knows anything else on authentication schemes or encrypting X connections? Maybe kerberos?


Next Previous Contents

The Linux Tutorial completely respects the rights of authors and artists to decide for themselves if and how their works can be used, independent of any existing licenses. This means if you are the author of any document presented on this site and do no wish it to be displayed as it is on this site or do not wish it to be displayed at all, please contact us and we will do our very best to accommodate you. If we are unable to accommodate you, we will, at your request, remove your document as quickly as possible.

If you are the author of any document presented on this site and would like a share of the advertising revenue, please contact us using the standard Feedback Form.


  




Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can help in many different ways.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.40 Seconds