LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2001-12-08 00:46:10 +00:00
parent 1e69abfe05
commit deed3c285f
1 changed files with 46 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
LDP/howto/linuxdoc/Remote-X-Apps.sgml
View File

@ -8,7 +8,7 @@
name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl"
name="zweije@xs4all.nl">
<date>v0.7.4, 2001-12-07
<date>v0.7.5, 8 December 2001
<abstract>
@ -55,25 +55,16 @@ name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. Linux
url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html"
name="sunsite.unc.edu">.
This is version 0.7.4. No guarantees, only good intentions. I'm open
This is version 0.7.5. No guarantees, only good intentions. I'm open
to suggestions, ideas, additions, useful pointers, (typo) corrections,
etc... I want this to remain a simple readable document, though, in the
best-meant HOWTO style. Flames to <tt>/dev/null</tt>.
best-meant HOWTO style. Flames to <tt>/dev/null</tt>. This document is
released under version 1.1 of the <htmlurl url="http://www.gnu.org/"
name="GNU"> Free Documentation Licence.
Contents last updated on 7 December 2001 by <htmlurl
Contents last updated on 8 December 2001 by <htmlurl
url="http://www.xs4all.nl/~zweije/index.html" name="Vincent Zweije">
<p>
This document is copyrighted 2001 by Vincent Zweije.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version
1.1 or any
later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts.
A copy of the license
is available at <htmlurl url="http://www.gnu.org/copyleft/fdl.html"
name="http://www.gnu.org/copyleft/fdl.html">.
<sect> Related Reading
<p>
@ -85,10 +76,12 @@ Kenny">. It suggests a similar solution to X authentication to that in
this document (xauth). However, Kevin aims more at using xdm to steer
xauth for you.
The X System Window System Vol. 8 X ``Window System Administrator's
The X System Window System Vol. 8 ``X Window System Administrator's
Guide'' from <htmlurl url="http://www.ora.com/" name="O'Reilly and
Associates"> has also been brought to my attention as a good source of
information. Unfortunately, I've not been able to check it out.
Associates"> has also been brought to my attention and confirmed as a
good source of information. However, it has not been revised since its
original publication in 1992. As such it only covers X11R4 and X11R5,
anything specific to X11R6 will not be covered.
Yet another document much like the one you're reading
now, titled ``Securing X Windows'', is available at <htmlurl
@ -319,9 +312,14 @@ 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
<tt>&tilde;/.Xauthority</tt>. Your <tt>&tilde;/.Xauthority</tt> must be inaccessible
for group/other users. The xauth program manages these cookies, hence
the nickname xauth for the scheme.
<tt>&tilde;/.Xauthority</tt>. Your <tt>&tilde;/.Xauthority</tt> 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 <tt/XAUTHORITY/
environment variable, but you will rarely need this. If you're not sure
which cookie file your xauth is using, do an <tt/xauth -v/, and it will
tell you.
On starting a session, the server reads a cookie from the file that
is indicated by the <tt/-auth/ argument. After that, the server only
@ -519,11 +517,27 @@ other's cookies.
<p>
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 will do X forwarding over encrypted connections. And
besides, it's great in other ways too. It's a good structural improvement
to your system. Just visit <htmlurl url="http://www.ssh.org/"
name="http://www.ssh.org/">, the ssh home page.
the secure shell. It can do X forwarding over encrypted connections.
To turn on X forwarding over ssh, use the command line switch <tt/-X/
or write the following in your local ssh configuration file:
<tscreen><verb>
Host remote.host.name
ForwardX11 yes
</verb></tscreen>
The ssh server (<tt/sshd/) at the remote end automatically sets
<tt/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 <tt>~/.Xauthority</tt> 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 <htmlurl
url="http://www.ssh.org/" name="http://www.ssh.org/">, the ssh home page.
<p>
Who knows anything else on authentication schemes or encrypting X
connections? Maybe kerberos?
@ -631,6 +645,12 @@ xsu clientuser 'command &'
Can't be much easier, unless you get rid of the password. Yes, there
are ways for that too (<tt/sudo/), but this is not the place for that.
<p>
The tiny <tt/xsu/ script just mentioned has served as the basis for a
more extended script called <tt/sux/ which apparently has found its way
as a package into the <htmlurl url="http://www.debian.org/" name="Debian">
distribution.
<sect1> Client User Is Root
<p>
@ -924,7 +944,7 @@ Whether you should want to provide any host in Internet with an X
session is arguable. Obviously, any service you provide is one more
possible hole in your server's security. On the other hand, the server
should be secure itself, and an XDMCP client asking for an X session
has to privide a valid authentication before the X session is granted.
has to provide a valid authentication before the X session is granted.
<p>
Furthermore, the X session uses a remote X connection, which is