2001 年 12 月 01 日
本文是两篇比较 SSH、远程 X、VNC 和其它技术作为远程运行应用程序方法的文章的第 2 部分。在这一部分中，David 研究了一些 VNC 配置问题，提到了 IBM 的 Desktop On-Call，介绍了远程 X 并讨论了一些有关安全性的问题。
在有关共享计算机的这两篇文章中的
第 1 部分中，
我描述了我的异构本地网络以及如何使用它来比较和测试不同操作系统和体系结构上的应用程序。
有几种技术使一台工作站上的用户可以运行位于另一台工作站上的应用程序。SSH
提供到远程计算机的文本终端；可以使用 X Window 系统在一个并未实际运
行交互式应用程序的工作站上显示该应用程序；VNC 可以作为对整个远程台式机的“遥控器”。
每种技术都有优缺点。它们都在 Linux 上运行，
但不同变体（主机或远程）都允许与异构网络的其它各种 OS 环境进行交互。
使用这些工具的组合，我可以坐在一台工作站（比方说，具有最好的显示器、键盘和椅子的那一台）上，然后运行和测试多个平台上
的应用程序并对它们设定运行时间 ― 通常不用重新引导任何系统。
第 1 部分介绍了 SSH 和 VNC。第 2 部分将更多地讨论 VNC，然后再讨论远程 X 和安全性。
我的网络设置
我的
本地网络上有七个节点，分别命名为 Apollo、Bacchus、Chaos、Delphi、Echo、Fury 和
Gaia。按所列的次序为这些节点分配了从 192.168.1.101 到 192.168.1.107 的本地 IP
地址。大多数情况下，同一物理机器在多重引导到不同 OS 时总是获得相同的 IP 地址（但有时我使用 DHCP，它分配
192.168.1.200
以上的地址）。整个网络位于一个硬件防火墙／路由器后，而且我充分信任防火墙，以至于对于运行在本地机器上的服务，我也许并没有象应有的那样猜疑提防。需
要在公共因特网上共享计算机的读者应该比我更担心安全性问题。上面的详细信息将让读者理解下面给出的一些 shell 示例。我实际坐在
Bacchus 面前，它的 IP 地址是 192.168.1.102。
配置 VNC
在
第 1 部分中，
我演示了如何在 Linux 平台上启动 VNC，并且考虑了一些有关屏幕分辨率和颜色深度的问题，
但没有考虑有关配置和使用 VNC 的一些重要内容。
本文只集中讨论类 UNIX 的
Xvnc 服务器的使用。除了实现配置不同外，其它系统都有相似的概念，它们通常通过菜单和对话框，而不是通过命令行和配置文件进行配置。
当
vncserver 首次运行在一个给定的用户帐户内时，它要求您指定 VNC 客户机连接需要的密码。另外，创建了一些缺省配置文件。请看一下它的首次运行：
创建缺省 VNC 配置
[vnc-user@fury vnc-user]$ vncserver
You will require a password to access your desktops.
Password:
Verify:
New 'X' desktop is fury.gnosis.lan:3
Creating default startup script /home/vnc-user/.vnc/xstartup
Starting applications specified in /home/vnc-user/.vnc/xstartup
Log file is /home/vnc-user/.vnc/fury.gnosis.lan:3.log
|
这里，我创建了一个 VNC 会话。尽管在命令行上没有指定别的分辨率，将使用缺省分辨率。
缺省分辨率是 1024 x 768，而缺省颜色深度是 8 位。
第 1 部分演示了如何创建使用其它分辨率的脚本文件。
一开始要注意的事情是在首次运行期间创建的
~/.vnc/xstartup 文件。
该文件控制创建 VNC 会话时发生的事情 ― 最需注意的是使用哪个窗口管理器。
首次创建
~/.vnc/xstartup 时，指定的窗口管理器是
twm ，
它是一个极小的窗口管理器，几乎每台 X Window 系统机器上都有 twm。从好的方面讲，
twm
的极小本质几乎使它可能成为运行 VNC 的最为“带宽友好”的方法。从坏的方面讲，
twm 不具备完整“桌面管理器”（象 KDE、GNOME 或 WindowMaker）的大部分花哨功能。
许多用户都想要编辑他们的
xstartup 。下面是我修改过的示例：
定制的 VNC“启动”
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
#exec wmaker
exec startkde
|
在上面的示例中，我注释掉了缺省
twm 和
xterm 的缺省启动。我还注释掉了我曾使用了一段时间的 WindowMaker 的启动。
实际上我并没有删除那些行，以防以后想要恢复它们。
我利用这个帐户实际上是为了启动 KDE。不过，我配置了这个特殊的 KDE 桌面
来避免背景和标题栏上的颜色渐变，并使用极少的动画效果。使桌面的繁忙程
度最小化可使 KDE 在通道带宽上变得更宽松。相似的原理适用于您所喜欢的任何一个窗口管理器。
最后要注意的是杀死已启动的 VNC 会话。
需要在服务器端完成这个任务（包括从
vncviewer 窗口，一旦杀死该服务器，该窗口将切断连接；但
这不会引起任何损害）。
查看已经启动了哪些 VNC 会话的快速方法是使用
ps -ax | grep vnc 。
如果您想结束某个会话，可以使用 Linux 的
kill 命令，但这会留下一些悬而未决的信号文件，需要您稍后手工删除它们。更干净的方法通常是使用
vncserver -kill :1 － 但如果要从 root 帐户强制杀死用户
VNC 进程，则使用
kill 命令。
Desktop On-Call 和 eComStation
developerWorks 上我写的“可爱的 Python”专栏和这两篇文章的读者
可能已经对我偶然提及 OS/2 的使用稍感惊讶，因为使用它的人数已在几年内
逐步减少（甚至在 IBM 内部更是如此）。
我的“正式”说法是大概观察到：OS/2 Warp 的 Workplace Shell 仍远远领先于已
经在 Linux、Windows、MacOS 或者甚至是 BeOS 上出现的任何 GUI。WPS 确实很好，但我继续使用的实际原因主要是我这部分的惯性使然。好几年以来，我构建了我所熟悉并很适合在 OS/2 上使用的大型工具集，而且它们彼此工作得很好。
当引导到其它系统时，我从来没有设法填补日常使用的所有不足（90% 的快乐仍需来源于偶然的重新引导）。
由于我的倔强，最近我因接收到一份 Serenity 系统的 eComStation 评估员副本而激动，
它是由第三方获许可者对 IBM 的 Warp 4.5/Workspace on Demand 所做的增强和重新绑定。eComStation（eCS）只是今年才发行的，
它包括“Warp 核心”的所有最新补丁和大量额外工具。
与 eCS 包括在一起的工具之一是名为“Desktop On-Call (DToC)”的 IBM 产品。
还有 Windows 和 Linux 版的 DToC 服务器，但很难在美国买到。DToC 所做的事情很象 VNC 所做的。DToC
服务器依附 HTTP 协议上（缺省情况下，使用端口
80），以通过网络（LAN 或因特网）为“远程台式机”提供服务。DToC
的客户机应用程序是任何启用了 JavaScript 和 Java 的 Web 浏览器。与使用
VNC Java 客户机一样，Web 浏览器基本上是至 DToC 的连接接口。而且，DToC
也有与 VNC 完全相同的问题：本地捕捉的击键、多键序列和带宽／分辨率权衡问题。
与 VNC 相比，DToC 有两个优点。安全性问题被集成到 DToC 中，而不是通过需要分别配置的其它层和转换。
依附在 HTTP 上意味着 DToC 比 VNC 更容易通过防火墙（但这有利有弊）。
此外，您会在 DToC 内部获得文件传送接口，
所以只要 DToC 在运行，就无须在服务器上运行单独的 FTP、Samba、NFS 或类似的文件传送服务器。
从不利方面看，总的说来，比起 VNC，DToC 感觉上响应较慢 ― 这并不可怕，但少许差了点。
与 eCS 绑在一起的另一个工具是名为 Hoblink X11 的 X 服务器。我至今还未对它进行过实验，
但当我对它进行实验时，这可能会使得为我本地网络的 OS/2 节点带来更好的集成（但还是 Linux “良好合作”做得最好）。
远程 X Window 系统
X Window 系统是响当当的软件思想。
尤其知道它首次于 1984 年发明（在 Microsoft Windows 1.0 之前且刚好在第一台
Macintosh 之后的一小段时间)就更了不起了。对于大多数 Linux 用户而言，X Window 系统（或“X11”，
但正确地讲
不是“X Windows”）可能只是其窗口管理器为在本地显示 GUI 应用程序而调用的 API。
但实际上 X11 是更有趣的东西。
X11 总是有一个客户机和一个服务器，即使当它们都运行在同一台实际机器上。X 客户机和 X
服务器或许会与人们最初认为它们是服务器或客户机的想法相反。X 服务器是乐意为底层的应用程序提供显示能力的设备。X 客户机是一种希望某个 X 服务器向它提供放置其可视输出的地方的特殊应用程序。
在本地工作站上运行时，服务器和客户机完全在一个内部通道上通信。
但当涉及到本地和远程机器时，本地机器通常是 X 服务器，而远程机器通常是 X 客户机。
然而，有时候您可能想要在您不在的工作站上显示某些信息，角色可能会颠倒。
X Window 系统本身实际只是一个具有诸如“在这些坐标上绘制一个窗口”等调用的 API。
为了实际让 X Window 系统做更多的事情，通常在它的上面运行一个
窗口管理器，
让您做一些如移动窗口、使它们最小化和启动新的 X 客户机等事情。
让我们看一下如何启动一个远程应用程序（X 客户机），以使它在本地工作站上显示。用于演示的所有机器都是 Linux，但其它具有 X 服务器和客户机的系统将以相似的方式工作。首先，我们要决定本地机器使用的 IP 地址；
ifconfig 是完成这个任务的好工具：
查找本地机器（X 服务器）的 IP 地址
[root@bacchus /root]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:48:54:83:82:AD
inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:15933 errors:0 dropped:0 overruns:0 frame:0
TX packets:10426 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0xe800
|
接下来，要确保远程机器上的应用程序将具有使用本地 X 服务器的本地许可权：
设置 X 服务器权限（首先全部除去）
[root@bacchus /root]# xhost -
access control enabled, only authorized clients can connect
[root@bacchus /root]# xhost +192.168.1.106
192.168.1.106 being added to access control list
|
接下来，需要能够启动应用程序以在远程机器上运行。
我们
可能会转到实际机器（或让其他人转去），但大多数情况下，打开远程
shell 会话是最简单的事情（这里，使用不安全的
telnet 方式）：
连接到远程机器 Fury（X 客户机）
[root@bacchus /root]# telnet -l quilty 192.168.1.106
Trying 192.168.1.106...
Connected to 192.168.1.106.
Escape character is '^]'.
Password:
Last login: Tue Nov 27 18:07:51 from 192.168.1.201
|
如果一切都运行正常，远程机器将自动检测正在连接的机器。有关在不正常情况下要做些什么事情的信息，则请参阅下面的内容：
检查 X 客户机 Fury 上的 DISPLAY 环境变量
[quilty@fury quilty]$ echo $DISPLAY
bacchus.gnosis.lan:0
|
现在，我们可以启动 X 客户机。对于本示例，使用普通的（但挺有意思的）应用程序
xeyes （它在屏幕上显示一双跟随鼠标光标的眼睛）：
在 X 客户机上启动应用程序以在 X 服务器上显示
[quilty@fury quilty]$ xeyes &
[1] 9939
|
启动远程应用程序时的一些故障
偶而，上述序列中的某些事情会发生故障。请看一下一些典型问题：
连接到远程机器 Delphi
[root@bacchus /root]# /usr/local/bin/ssh quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Wed Nov 28 01:06:08 2001 from 192.168.1.201
Linux 2.2.19.
|
请尝试执行上面的序列：
检查 X 客户机 Delphi 上的 DISPLAY 环境变量
quilty@delphi:~$ echo $DISPLAY
quilty@delphi:~$ xeyes &
[1] 17668
quilty@delphi:~$ Error: Can't open display:
[1]+ Exit 1 xeyes
|
由于没有自动检测到
DISPLAY 环境变量的值，所以 X 客户机不知道哪个服务器将为它提供显示：
没有（或错误地）设置 DISPLAY，export 值
quilty@delphi:~$ export DISPLAY=192.168.1.102:0
quilty@delphi:~$ xeyes &
[1] 17669
quilty@delphi:~$ Xlib: connection to "192.168.1.102:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: 192.168.1.102:0
[1]+ Exit 1 xeyes
|
继续前进，但 Bacchus 尚未授权 Delphi 使用它的 X 服务器（我们需要切换到本地 xterm 来修正这个问题）：
X 服务器拒绝连接；启用它
[root@bacchus /root]# xhost +192.168.1.104
192.168.1.104 being added to access control list
|
一切都正常：
在 X 客户机上启动应用程序以在 X 服务器上显示
quilty@delphi:~$ xeyes &
[1] 17670
|
安全性问题
在
第 1 部分中，
我曾经提到 VNC 和远程 X11 在因特网通道上都是不安全的。整个远程显示在
公共路由器上是在未经加密的情况下传输的。
我不担心防火墙后面的专用 LAN。
但是，如果我想要使用这些技术在全世界范围（或者甚至跨城市）共享远程计算机，那么 VNC 或 X11
协议应该被放置在 SSH 上。做到这一点真的没有任何损失，而且 SSH 甚至（可选地）添加其自己的压缩层来增强性能。
但是，您需要配置它。
要在 SSH 上配置 VNC，最好是阅读文章“Making VNC more secure using SSH”（请参阅本文后面的
参考资料）。
这篇文章写得很好，描述了我可能要讲到的每一件事情。
将 X 放置在 SSH 上十分容易做到。假设正在使用 OpenSSH，
将需要修改名为
sshd_config 的文件来允许分层。
不同的 Linux 分发版将该文件放在稍微不同的地方。Mandrake 7.1
将它放在
/usr/local/etc/ ；Slackware 7.0 使用
/etc/ssh/ 。在任何情况下，
您都必须确保该文件包含下列内容：
将需要重新启动
sshd 守护程序来激活该设置。
实际上，一旦正确配置了
sshd ，就可以更容易地启动 X 客户机，以在本地 X 服务器上显示：
对于 X 客户机使用 sshd X11 转发
[quilty@bacchus quilty]$ ssh -X quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Fri Nov 30 16:53:03 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ echo $DISPLAY
delphi:10.0
quilty@delphi:~$ xeyes &
[1] 201
|
请注意，即使已连接到 Delphi，
DISPLAY 变量仍似乎会指出 X 服务器在 Delphi 上。在某种程度上，就是这样，正讨论的 X 服务器是将显示交付给适当的远程计算机的 SSH 守护程序。
参考资料
IBM Desktop On-Call 参考资料
X Window 系统参考资料
-
XFree86网站是查看与这一受欢迎的自由软件 X Window 实现相关的所有信息的好地方。
- 从技术上讲，XFree86 是正式的 X Window 系统的克隆（很象 Linux 是 UNIX 的“克隆”那样）。
实际上，您不必担心什么是正式的 － 所有版本彼此都会很好地合作。有关正式系统的信息（包括可用的源代码），
请转至
X.org 主页。
- 还可以获得 X Window 系统的许多商业实现：
其它参考资料
关于作者