服务器不会接受来自任何地方的连接。您不希望任何人都能在您的屏幕上显示窗口。或者读取您输入的内容 -- 请记住，您的键盘是显示器的一部分！
似乎很少有人意识到允许访问您的显示器会带来安全风险。任何有权访问您显示器的人都可以读取和写入您的屏幕内容、读取您的击键以及读取您的鼠标操作。
大多数服务器知道两种验证连接到自身的方式：主机列表机制 (xhost) 和魔法 Cookie 机制 (xauth)。然后是 ssh，安全 shell，它可以转发 X 连接。
请注意，一些 X 服务器（来自 XFree86）可以配置为不监听常用的 TCP 端口，使用 -nolisten tcp 参数。值得注意的是，Debian GNU/Linux 的默认配置是禁用 X 服务器监听 TCP 端口。如果您希望在 Debian 系统上使用远程 X，您应该通过更改 X 服务器的启动方式来重新启用此功能。查看 /etc/X11/xinit/xserverrc 以开始。
Xhost 允许基于主机名进行访问。服务器维护一个允许连接到它的主机列表。它也可以完全禁用主机检查。注意：这意味着不进行任何检查，因此每个主机都可以连接！
您可以使用 xhost 程序控制服务器的主机列表。要在之前的示例中使用此机制，请执行
light$ xhost +dark.matt.er
这允许来自主机 dark.matt.er 的所有连接。一旦您的 X 客户端建立连接并显示窗口，为了安全起见，请使用以下命令撤销更多连接的权限
light$ xhost -dark.matt.er
您可以使用以下命令禁用主机检查
light$ xhost +
这将禁用主机访问检查，从而允许所有人连接。在您不信任所有用户的网络（例如互联网）上，您绝不应该这样做。您可以使用以下命令重新启用主机检查
light$ xhost -
xhost 本身不会从访问列表中删除所有主机（这将是完全无用的 - 您将无法从任何地方连接，甚至包括您的本地主机）。
Xhost 是一种非常不安全的机制。 它不区分远程主机上的不同用户。此外，主机名（实际上是地址）可能会被欺骗。如果您在不受信任的网络上（例如已经通过拨号 PPP 访问互联网），这很糟糕。
Xauth 允许任何知道正确密钥的人访问。这样的密钥称为授权记录，或魔法 cookie。这种授权方案正式称为 MIT-MAGIC-COOKIE-1。
不同显示器的 cookie 存储在 ~/.Xauthority 中。您的 ~/.Xauthority 必须对组/其他用户不可访问。xauth 程序管理这些 cookie，因此该方案的昵称是 xauth。
您可以使用 XAUTHORITY 环境变量指定不同的 cookie 文件，但您很少需要这样做。如果您不确定您的 xauth 正在使用哪个 cookie 文件，请执行 xauth -v，它会告诉您。
在启动会话时，服务器从 -auth 参数指示的文件中读取 cookie。之后，服务器仅允许来自知道相同 cookie 的客户端的连接。当 ~/.Xauthority 中的 cookie 更改时，服务器不会接受更改。
较新的服务器可以为请求它的客户端动态生成 cookie。cookie 仍然保存在服务器内部；除非客户端将它们放在那里，否则它们不会最终出现在 ~/.Xauthority 中。根据 David Wiggins 的说法
在 X11R6.3 中添加了一个您可能感兴趣的进一步复杂之处。通过新的 SECURITY 扩展，X 服务器本身可以动态生成并返回新的 cookie。此外，cookie 可以被指定为“不可信”，以便使用此类 cookie 进行连接的应用程序将受到操作限制。例如，他们将无法从其他受信任的客户端窃取键盘/鼠标输入或窗口内容。xauth 中有一个新的“generate”子命令，使此功能至少可以使用，即使不是很简单。
Xauth 比 xhost 具有明显的安全优势。您可以将访问权限限制为特定计算机上的特定用户。它不像 xhost 那样受到欺骗地址的影响。如果您愿意，您仍然可以在旁边使用 xhost 来允许连接。
如果您想使用 xauth，您必须使用 -auth authfile 参数启动 X 服务器。如果您使用 startx 脚本，那是正确的地方。在您的 startx 脚本中如下创建授权记录。
摘自 /usr/X11R6/bin/startx
mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
Mcookie 是 util-linux 包中的一个小程序，主要站点 ftp://ftp.math.uio.no/pub/linux/。或者，您可以使用 md5sum 将一些随机数据（例如来自 /dev/urandom 或 ps -axl）转换为 cookie 格式
dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"
如果您无法编辑 startx 脚本（因为您不是 root 用户），请让您的系统管理员正确设置 startx，或让他设置 xdm 代替。如果他不能或不愿意，您可以制作一个 ~/.xserverrc 脚本。如果您有此脚本，则由 xinit 而不是真正的 X 服务器运行它。然后，您可以从此脚本使用正确的参数启动真正的 X 服务器。为此，请让您的 ~/.xserverrc 使用上面的魔法 cookie 行来创建 cookie，然后 exec 真正的 X 服务器
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
如果您使用 xdm 管理您的 X 会话，您可以轻松使用 xauth。在 /etc/X11/xdm/xdm-config 中定义 DisplayManager.authDir 资源。Xdm 将在启动时将 -auth 参数传递给 X 服务器。当您然后在 xdm 下登录时，xdm 会将 cookie 放入您的 ~/.Xauthority 中。有关更多信息，请参阅 xdm(1)。例如，我的 /etc/X11/xdm/xdm-config 中有以下行
DisplayManager.authDir: /var/lib/xdm
现在您已经在服务器主机 light.uni.verse 上启动了您的 X 会话，并且在 ~/.Xauthority 中拥有了您的 cookie，您将必须将 cookie 传输到客户端主机 dark.matt.er。有几种方法可以做到这一点。
最简单的方法是当您在 light 和 dark 上的主目录是共享的时。~/.Xauthority 文件是相同的，因此 cookie 会立即传输。但是，有一个陷阱：当您将 :0 的 cookie 放入 ~/.Xauthority 时，dark 会认为它是它自己的 cookie，而不是 light 的 cookie。您在创建 cookie 时必须使用显式主机名；您不能省略它。您可以使用这个小的 sed 技巧为 :0 和 light:0 安装相同的 cookie
#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
rsh如果主目录未共享，您可以使用 rsh（远程 shell）传输 cookie
light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -
~/.Xauthority 中提取 cookie (xauth nlist :0)。| rsh dark.matt.er)。~/.Xauthority 中 (xauth nmerge -)。
请注意 ${HOST} 的使用。您需要传输与本地主机显式关联的 cookie。远程 X 应用程序会将显示值 :0 解释为引用远程计算机，这不是您想要的！
rsh 可能不适合您。除此之外，rsh 也存在安全缺陷（如果我没记错的话，又是欺骗主机名）。如果您不能或不想使用 rsh，您也可以手动传输 cookie，例如
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$
另请参阅 rsh(1) 和 xauth(1x) 以获取更多信息。
当您 telnet 到远程主机时，有可能将 cookie 附加到 TERM 或 DISPLAY 变量上。这与将 DISPLAY 变量附加到 TERM 变量的方式相同。请参阅第 5 节：告知客户端。从我的角度来看，您需要自己探索，但我有兴趣是否有人可以确认或否认这一点。
但是请注意，在某些 Unix 系统上，其他人可以观察到环境变量，如果您的人正在寻找它，您将无法阻止 $TERM 中的 cookie 显示出来。
dark.matt.er 上的 X 应用程序（例如上面的 xfig）将自动在 ~/.Xauthority 中查找 cookie 以进行身份验证。
使用 localhost:D 时有一个小问题。X 客户端应用程序将 localhost:D 转换为 host/unix:D 以用于 cookie 检索。实际上，这意味着 ~/.Xauthority 中 localhost:D 的 cookie 没有效果。
如果您仔细考虑一下，这才是合乎逻辑的。对 localhost 的解释完全取决于解释它的机器。当您拥有通过 NFS 共享的主目录时，多个主机相互干扰 cookie，这会造成可怕的混乱。
授权记录通过网络传输，没有加密。如果您甚至担心有人可能会窥探您的连接，请使用 ssh，安全 shell。它可以对加密连接进行 X 转发。
要启用通过 ssh 的 X 转发，请使用命令行开关 -X 或在您的本地 ssh 配置文件中写入以下内容
Host remote.host.name
ForwardX11 yes
远程端的 ssh 服务器 (sshd) 会自动将 DISPLAY 设置为指向其 X 转发隧道的末端。远程隧道末端获得自己的 cookie；远程 ssh 服务器为您生成它并将其放入那里的 ~/.Xauthority 中。因此，使用 ssh 进行 X 授权是完全自动的。
顺便说一句，ssh 在其他方面也很棒。它是您系统的一个良好的结构性改进。欲了解更多信息，请访问 http://www.ssh.org/，ssh 官方网站。
还有谁知道关于身份验证方案或加密 X 连接的其他信息吗？也许是 Kerberos？