一般在命令行执行需要界面的程序,一般都会报 display找不到,或者说你的¥DISPAY环境变量没置的错误。这时就要通过设置DISPLAY环境变量为一个存在的显示器,还有通过xhost/xauth来设置显示器的权项。(xhost是久的,一般推荐用xauth了吧,xauth的安全控制更好一些。)
情况1.
[root@ ~]# /usr/lib/firefox-1.5.0.12/firefox
(firefox-bin:24779): Gtk-WARNING **: cannot open display:
--------------
解决办法,执行如下命令。
export DISPLAY=:0.0 设置默认的显示器
xhost +LOCAL: 开放 本地连接xserver的权限
情况2.
[root@~]# xhost +LOCAL:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
xhost: unable to open display ":0.0"
------------------------
[root@ ~]# startx
xauth: creating new authority file /root/.serverauth.19320
Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
giving up.
xinit: unable to connect to X server
xinit: No such process (errno 3): Server error.
-------------------------------------------------------------------------
解决办法一:
export DISPLAY=:0.0 设置默认的显示器
init 3 关闭 xserver ,要先init 3 了才能startx ,startx后权限自动会被写到/root/.Xauthority 文件里面去,这样xauth list 就能显示正确的cookie ,xhost +LOCAL: 也会正常工作。
startx 启动server
xauth list 检查 xserver的连接权限
xhost +LOCAL: 开放 本地连接xserver的权限
如果这都不能解决问题, 去学学上面几个命令吧 ,man init ,man xauth 等,
解决方法二:
这个问题可能是这种情况,Xorg 这个xserver进程是被gdm 等启动的,但xserver启动后,他不会像使用startx来启动一样把MIT-MAGIC-COOKIE写到 /root/.Xauthority 里面去,所以root想启动带gui的程序时就会出现没有权限的错误,就是那个MIT-MAGIC-COOKIE-1没有存在或者是错误的。这样的话,可以自己根据ps命令查出来的Xorg进程的状态,因为虽然他没有自动配置 /root/.Xauthority 文件,但他是生成一个认证的文件放在/var/gdm/:0.Xauth里面的。我们可以用xauth list来查看这个文件得到正确的MIT-MAGIC-COOKIE-1,然后自己把它添加到 /root/.Xauthority 文件里面去。这样也能解决问题。
[root@ ~]# ps -ef |grep X
root 14796 14789 1 23:55 tty8 00:00:01 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt8
root 14834 14510 0 23:57 pts/1 00:00:00 grep X
-------------------------------------
[root@ ~]# xauth -f /var/gdm/:0.Xauth list
#ffff##:0 MIT-MAGIC-COOKIE-1 6755317d62ce89e598dad3da65b14167
这个文件里的是正确的key
---------------------
[root@ ~]# xauth list
XXXXX/unix:0 MIT-MAGIC-COOKIE-1 3a03381e5745b7aad7477825c30740b4
localhost.localdomain:0 MIT-MAGIC-COOKIE-1 3a03381e5745b7aad7477825c30740b4
这个是 /root/.Xauthority 里面 的错误key
------------
[root@ ~]# xauth remove XXXXX/unix:0
[root@ ~]# xauth remove localhost.localdomain:0
--------------------------
[root@ ~]# xauth add XXXXX/unix:0 . 6755317d62ce89e598dad3da65b14167
[root@~]# xauth add localhost.localdomain:0 . 6755317d62ce89e598dad3da65b14167
---------------------------
[root@ ~]# xauth list
XXXXX/unix:0 MIT-MAGIC-COOKIE-1 6755317d62ce89e598dad3da65b14167
localhost.localdomain:0 MIT-MAGIC-COOKIE-1 6755317d62ce89e598dad3da65b14167
删掉再自己添加进来之后,这里就是正确的key了。
注意 XXXXX/unix 表示 XXXXX这个host采用的事unix socket协议,只允许本地连接的那种.
localhost.localdomain:0这种中间没有/unix的才允许远程tcp连接的,参考下面的xerver配置说明。
如果有时用终端登录过去也要为本地的display配置以下,程序才能找到相应的DISPLAY.
推荐使用第二种方法吧,因为这样不需要用init3 init5 进行切换,也可以避免使用startx,不知道startx和init 5的配置是不是一样的。还是init 5 之后用 第二种办法自己修改 magic cookie来的好一些。
==============================================
在Ubuntu上面 的测试:
按照上面设置的办法,还是不能工作。再检查以下一下本地 xserver的设置
widebright@gdeng:~/桌面$ ps -ef | grep X
root 1246 1217 5 09:55 tty7 00:09:53 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-LzFa8c/database -nolisten tcp vt7
用 man xserver可以看到,-nolisten tcp 选项已经禁用远程机器的tcpip 来连接到自己的 display了。也就是说默认ubuntu的xserver事不允许远程机器显示窗体到这个显示器上的,听说这样会有安全问题吧。
----------------------------
要gdm支持 tcp远程连接,需要修改/etc/gdm/gdm.schemas 文件的
DisallowTCP 选项为true,才能允许远程机器连到自己的xserver
-----------------------
/etc/gdm/gdm.schemas
<schema>
<key>security/DisallowTCP</key>
<signature>b</signature>
<default>true</default> 这里要改成false
</schema>
--------------------
修改后,注销系统,重新登录
widebright@gdeng:~/桌面$ ps -ef |grep X
root 2548 2547 8 14:41 tty7 00:00:02 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-zcq34j/database
1000 2883 2852 0 14:41 pts/0 00:00:00 grep --color=auto X
可以看到 -nolisten tcp 选项已经没有了。
注意重启之后,xserver的 xauth key 已经重新生成了,所以需要再本机上检查 xauth list 检查一下新的key ,然后用xauth remove xauth add 来设置新的display。
man xauth的文档说 可以直接这样把 他导入到远程机器上:
xauth extract - $DISPLAY | rsh otherhost xauth merge -
------------------
我试了一下,是可以 xauth extract - $DISPLAY | ssh user@hostname xauth merge - 这样导过去的,不过本地 display 不一定再远程机器上也可以用的。所以还是自己使用xauth remove xauth add 来添加的好一些。
xauth add hostname:0 MIT-MAGIC-COOKIE-1 58071020697bc1326a95ea2b2b1ac904
确保 hostname 是正确的,和 MIT-MAGIC-COOKIE-1的值是对的(xserver重启之后,这个key事重新生成的)。
直接 xauth extract 过去的是 hostname/unix:0 这种,hostname不一定事远程机器可以访问的,而且中间的unix表示采用unix socket协议,只是本地使用才可以的。远程的应该tcp协议的。
==========================================
还有一个办法就是利用 ssh 的 -X选项,这样就不用配置那些xauth的信息了。
在ubuntu上的话,首先在服务器上安装 openssh-server 包。
查看ssh server的配置文件/etc/ssh/sshd_config 里面
X11Forwarding yes已经开放
然后用
ssh -X user@hostname 连接过去检查DISPLAY环境变量
echo $DISPLAY
localhost:10.0
可以可到ssh 已经帮你设置了一个 虚拟的display 。然后不用带--display参数运行firefox等命令的时候,就自动显示在本地的 xserver上面了。
注意,这个是ubuntu环境你本地的xserver已经可以正确工作的情况下的,如果再windows环境用putty的话,他也是支持x11 forwarding的,但就可能需要你指定个可以用display给他的,windows的话可以安装 Xming (http://www.straightrunning.com/XmingNotes/)或者 Xmanger等为windows平台的xserver 实现,然后很多工具用起来还挺好用的。当然你也可以在参数里面填一个远程的linux平台的xserver的display给putty作为参数。
详细的说明可以参考一下ssh的文档或和这个网站
http://www.techotopia.com/index.php/Displaying_Ubuntu_Linux_Applications_Remotely_%28X11_Forwarding%29
===================
这样就是不用配置本地的xserver 监听tcp的端口,可能安全性行更好吧(第一种方法xserver采用的 xdmcp协议是不加密的,键盘事件等都可能被别人监控到。)。但需要你能够配置远程机器上的ssh server权限才行。但有的时候远程机器只能telent连接过去,而且有不能装ssh server时,就可以用第一种办法,先配置好本地xserver (ubuntu的要开放tcp连接,windows 的Xming的话也需要xserver启动了吧),然后export DISPLAY环境变量或者用--display参数启动程序就可以了。
==================================
参考资料:
x11 security
=============
index
locking the console
X security and remote X
x11 screenlock applications
---------------------------
kde screensaver
kshutdown
http://kshutdown.sourceforge.net/
lock-keyboard-for-baby
http://csincock.customer.netspace.net.au/lock-keyboard-for-baby.htm
xscreensaver
fedora rpms: xscreensaver-base xscreensaver-extras xscreensaver-gl-extras
- run as a non-root user to use locking feature
note: xfce "lock" button uses xscreensaver
- time: see time.html for details on using xscreensaver for clock
others
~~~~~~~~~~~~~~
control-center
coldspot - not updated since 2002; requires another program such as xscreensaver to lock screen
gnome-screensaver
- runs as a daemon?
xautolock
- not a locker - just runs specified program after specified period
xdg-screensaver
xdg-screensaver lock
- impotent...
xlock
xlockmore
X security
-----------------------
See Xsecurity man page
The X window system allows remote access. By default, X uses TCP/IP at port 6000. If you are on computer B and want to run an X application on computer A but see it's output on computer B, two things are required:
- you need to tell computer B where to send the X11 application's output
- you need to tell computer A how to receive information from computer B
Obviously, you want computer A to discriminate regarding what it allows to be displayed on its X server so that any joe in the world isn't able to send X11 application output to computer A. Obviously, computer B is also interested in not having any old X application from anywhere try and send its output to computer B's X server.
The DISPLAY environment variable
----
- the X server can manage one or more DISPLAYS (generally a combination of monitor, keyboard, and mouse)
- the DISPLAY environment variable defines the name of the display - e.g.,
DISPLAY=:0
DISPLAY=localhost:10.0
- the format is hostname:sequence-number.n
- the hostname is the name of the computer where the X server runs
- the ".n" indicates that we are dealing with the nth screen (a single display can have multiple screens)
- the sequence-number is the display number
The X11 application (the client program relative to the X server) knows which display to connect to by inspecting the DISPLAY variable. For most X applications, you can use the "-display" command-line option to specifically direct the output - e.g.,
xdpyinfo -display localhost:11.0
the X server and authentication
-=-=
The X server doesn't accept connections from any computer. How does the server authenticate connections? First of all, the X server can be started so that it accepts no TCP/IP connections - check if this is the case by
1. the host system (xhost)
- this is relatively insecure - avoid it
2. the magic cookie system (xauth)
xhost
----
This command turns the X authority system on/off for Xserver program. It will also allow users to disable/enable authorization checking from a particular machine. IE: a user can allow anyone on a particular host (often a private workstation) to use his/her display without authorization. By default this command has full authorization enabled, no host in its `authorized' host list
Example:
prompt>> xhost
access control enabled, only authorized clients can connect
dragon
cornet
This means that any program running on either of the machine dragon or
cornet can place windows on your screen without any trouble. If the
program was not run on either of these machines, the user must have
a `authorization password' (See method 2).
Removing a machine
xhost -cornet
Adding a machine
xhost +cornet
Allowing use of your display from any machine (in the world)
xhost +
To return to normal
xhost -
Note, because of the unusal systax of xhost you can't use a
``-display host:0'' option with it, instead use the env command to
set the ``DISPLAY'' environment variable for just that command.
env DISPLAY=host:0 xhost
xauth
-=-=
Xauth will allow access to anyone who knows the "secret". The secret is the 'authorization record' or 'magic cookie'. For server Y to put its client window on computer X, server Y must have computer X's authorization record. The cookies for different displays are stored in ~/.Xauthority (use xauth -v to confirm this). Use xauth list to list the cookies. To use xauth, the X server must be started with the -auth authfile argument (true?).
Enabling Xauth:
- xauth will be enabled on a display when you are using the `xdm' program (the one that displays the initial login window if you're booting into level 5) - xdm will create a file in your home directory called ``.Xauthority''. This file holds a password, key, magic-cookie or X authorization to allow you to access your display regardless of your xhost permission.
- Xauthorization can also be enabled when you start a X session using the ``startx'' program. This involves setting up a .xserverrc file with the appropriate ``-auth {key}'' X server option.
Generating the .Xauthority file:
- normally xdm creates the .Xauthority file but, if not running xdm, you may need to use xauth to create the authority file:
xauth generate displayname protocolname
e.g.,
xauth generate
- see also mkxauth
mkxauth -c <host>
- create a local Xauthority database
xauth
This command allows uses to list/add/remove/copy X authorization passwords from a given (default the users) ".Xauthority" file. This is a binary file and this command is the only real way of reading this file. Also the command ensures that all authority files is only read/writable by the owner of the file, thus insuring file security. Only root can read/write any authority file.
To list this file type (assuming you are on dragon)
prompt>> xauth list
dragon.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 e102ba90f0f55f2108a9ee2526537845
The format of the list is:
# machine auth-type authorization (cookie)
Note: sometimes authorities from old sessions are also present. This is of
no importance as every session has a new authority password generated on
every login.
If you do not have xhost permission (method 1) you MUST have the current authority to the display you wish to access. For example a friend decided to give me access to his display on thorax. He did not however wanted to use xhost as he only wanted to give me permission -- not just anyone on machine I am working on. So he mailed (or other means) his current authority.
thorax.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 3704a0c7fd52c90eabf53892c0ba7ee1
So I then add this to my ``.Xauthority'' file
prompt>> xauth add thorax.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 3704a0c..etc
Now I have access to his display regardless of his xhost setup and can do anthing on his display that he can do, untill he (or I) kills the current X session. However unless I am in the same room it is difficult for me to actually see what I am doing without some sort of `spy' program, and I definatly do not have control over the mouse (physical, the cursor I could control) or the keyboard.
WARNING: If someone has permission to access your display (via either
xhost or xauth) they can not only open windows, but can also look at your
display, or kill various windows, and terminate your current session! See
Below for good reasons why you shouldn't allow this. The most common
reason for allowing such access seems to be for X window games.
troubleshooting
====
"unable to open display"
- is the X server running on the remote machine or is it in console mode w/everyone logged out?
- if not try rebooting into level 5 (with xdm running)
- is the X server accepting remote connections?
- check if your firewall is blocking connections
Systematically:
1. Verify X11 is working on the local host:
export | grep DISPLAY
xdpyinfo (should give no errors)
2. Verify that X11 is working for clients on the remotehost via ssh forwarding:
me@localhost$ ssh remotehost
[...]
me@remotehost$ echo $DISPLAY # check DISPLAY is set for X11 forwarding
localhost:21.0
me@remotehost$ xdpyinfo # check that X11 forwarding works - shouldn't give any errors
me@remotehost$ # test with simple app
===================
How to Kill and Restart X Server
A GUI is a very complex piece of software and there could be any number of reasons why it would lock up on you. If you need to kill your x server and then restart it, here are some tips:
Killing X server via Command
Type “init 3″ in your terminal and that should kill x server. If it doesn’t find the command, then switch to the root user by typing “su -” (you will need to know the root password).
Restarting X server
Simply use the keyboard combination CTRL+ALT+BACKSPACE. Some times this will help, but this combination will explicitly restart the X server.
Working with a Console
If the previous keyboard combination did not work then try CTRL+ALT+F1. This will not kill X server, it will simply open a full screen console. I believe Red Hat and Fedora Core have F1-F6 as options. If you want to switch back to a GUI environment use the keyboard combination CTRL+ALT+F7.
Processes
Once you’re in the full screen console mode, you will have to use the kill command to close X server. Unfortunately; you can’t simply type in “kill xserver”. You’ll have to find it’s process ID, using the ps command. The ps command displays a list of the current processes running on the machine. There are tons of options for this command, use man ps to find which option works for your situation.
Once you found the process ID for the process you want to end, type in kill {process_id}. Let’s assume your process id is 1344. You will type kill 1344 and presto that process is no longer functioning.
Init Command
If you want to get out of the full screen console and into a bonafied console environment, use the init command.
* init 1 - kills all processes and loads the user into a full console.
* init 5 - runs the multi-user and GUI scripts in rc.d/rc5, which will start your login manager and put you back into a GUI environment.
Starting X server
Once you have X server killed, or no longer running - you can either type in init 5 or startx to get X server up and running again. If all else fails, simply reboot.
情况1.
[root@ ~]# /usr/lib/firefox-1.5.0.12/firefox
(firefox-bin:24779): Gtk-WARNING **: cannot open display:
--------------
解决办法,执行如下命令。
export DISPLAY=:0.0 设置默认的显示器
xhost +LOCAL: 开放 本地连接xserver的权限
情况2.
[root@~]# xhost +LOCAL:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
xhost: unable to open display ":0.0"
------------------------
[root@ ~]# startx
xauth: creating new authority file /root/.serverauth.19320
Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
giving up.
xinit: unable to connect to X server
xinit: No such process (errno 3): Server error.
-------------------------------------------------------------------------
解决办法一:
export DISPLAY=:0.0 设置默认的显示器
init 3 关闭 xserver ,要先init 3 了才能startx ,startx后权限自动会被写到/root/.Xauthority 文件里面去,这样xauth list 就能显示正确的cookie ,xhost +LOCAL: 也会正常工作。
startx 启动server
xauth list 检查 xserver的连接权限
xhost +LOCAL: 开放 本地连接xserver的权限
如果这都不能解决问题, 去学学上面几个命令吧 ,man init ,man xauth 等,
解决方法二:
这个问题可能是这种情况,Xorg 这个xserver进程是被gdm 等启动的,但xserver启动后,他不会像使用startx来启动一样把MIT-MAGIC-COOKIE写到 /root/.Xauthority 里面去,所以root想启动带gui的程序时就会出现没有权限的错误,就是那个MIT-MAGIC-COOKIE-1没有存在或者是错误的。这样的话,可以自己根据ps命令查出来的Xorg进程的状态,因为虽然他没有自动配置 /root/.Xauthority 文件,但他是生成一个认证的文件放在/var/gdm/:0.Xauth里面的。我们可以用xauth list来查看这个文件得到正确的MIT-MAGIC-COOKIE-1,然后自己把它添加到 /root/.Xauthority 文件里面去。这样也能解决问题。
[root@ ~]# ps -ef |grep X
root 14796 14789 1 23:55 tty8 00:00:01 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt8
root 14834 14510 0 23:57 pts/1 00:00:00 grep X
-------------------------------------
[root@ ~]# xauth -f /var/gdm/:0.Xauth list
#ffff##:0 MIT-MAGIC-COOKIE-1 6755317d62ce89e598dad3da65b14167
这个文件里的是正确的key
---------------------
[root@ ~]# xauth list
XXXXX/unix:0 MIT-MAGIC-COOKIE-1 3a03381e5745b7aad7477825c30740b4
localhost.localdomain:0 MIT-MAGIC-COOKIE-1 3a03381e5745b7aad7477825c30740b4
这个是 /root/.Xauthority 里面 的错误key
------------
[root@ ~]# xauth remove XXXXX/unix:0
[root@ ~]# xauth remove localhost.localdomain:0
--------------------------
[root@ ~]# xauth add XXXXX/unix:0 . 6755317d62ce89e598dad3da65b14167
[root@~]# xauth add localhost.localdomain:0 . 6755317d62ce89e598dad3da65b14167
---------------------------
[root@ ~]# xauth list
XXXXX/unix:0 MIT-MAGIC-COOKIE-1 6755317d62ce89e598dad3da65b14167
localhost.localdomain:0 MIT-MAGIC-COOKIE-1 6755317d62ce89e598dad3da65b14167
删掉再自己添加进来之后,这里就是正确的key了。
注意 XXXXX/unix 表示 XXXXX这个host采用的事unix socket协议,只允许本地连接的那种.
localhost.localdomain:0这种中间没有/unix的才允许远程tcp连接的,参考下面的xerver配置说明。
如果有时用终端登录过去也要为本地的display配置以下,程序才能找到相应的DISPLAY.
推荐使用第二种方法吧,因为这样不需要用init3 init5 进行切换,也可以避免使用startx,不知道startx和init 5的配置是不是一样的。还是init 5 之后用 第二种办法自己修改 magic cookie来的好一些。
==============================================
在Ubuntu上面 的测试:
按照上面设置的办法,还是不能工作。再检查以下一下本地 xserver的设置
widebright@gdeng:~/桌面$ ps -ef | grep X
root 1246 1217 5 09:55 tty7 00:09:53 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-LzFa8c/database -nolisten tcp vt7
用 man xserver可以看到,-nolisten tcp 选项已经禁用远程机器的tcpip 来连接到自己的 display了。也就是说默认ubuntu的xserver事不允许远程机器显示窗体到这个显示器上的,听说这样会有安全问题吧。
----------------------------
要gdm支持 tcp远程连接,需要修改/etc/gdm/gdm.schemas 文件的
DisallowTCP 选项为true,才能允许远程机器连到自己的xserver
-----------------------
/etc/gdm/gdm.schemas
<schema>
<key>security/DisallowTCP</key>
<signature>b</signature>
<default>true</default> 这里要改成false
</schema>
--------------------
修改后,注销系统,重新登录
widebright@gdeng:~/桌面$ ps -ef |grep X
root 2548 2547 8 14:41 tty7 00:00:02 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-zcq34j/database
1000 2883 2852 0 14:41 pts/0 00:00:00 grep --color=auto X
可以看到 -nolisten tcp 选项已经没有了。
注意重启之后,xserver的 xauth key 已经重新生成了,所以需要再本机上检查 xauth list 检查一下新的key ,然后用xauth remove xauth add 来设置新的display。
man xauth的文档说 可以直接这样把 他导入到远程机器上:
xauth extract - $DISPLAY | rsh otherhost xauth merge -
------------------
我试了一下,是可以 xauth extract - $DISPLAY | ssh user@hostname xauth merge - 这样导过去的,不过本地 display 不一定再远程机器上也可以用的。所以还是自己使用xauth remove xauth add 来添加的好一些。
xauth add hostname:0 MIT-MAGIC-COOKIE-1 58071020697bc1326a95ea2b2b1ac904
确保 hostname 是正确的,和 MIT-MAGIC-COOKIE-1的值是对的(xserver重启之后,这个key事重新生成的)。
直接 xauth extract 过去的是 hostname/unix:0 这种,hostname不一定事远程机器可以访问的,而且中间的unix表示采用unix socket协议,只是本地使用才可以的。远程的应该tcp协议的。
==========================================
还有一个办法就是利用 ssh 的 -X选项,这样就不用配置那些xauth的信息了。
在ubuntu上的话,首先在服务器上安装 openssh-server 包。
查看ssh server的配置文件/etc/ssh/sshd_config 里面
X11Forwarding yes已经开放
然后用
ssh -X user@hostname 连接过去检查DISPLAY环境变量
echo $DISPLAY
localhost:10.0
可以可到ssh 已经帮你设置了一个 虚拟的display 。然后不用带--display参数运行firefox等命令的时候,就自动显示在本地的 xserver上面了。
注意,这个是ubuntu环境你本地的xserver已经可以正确工作的情况下的,如果再windows环境用putty的话,他也是支持x11 forwarding的,但就可能需要你指定个可以用display给他的,windows的话可以安装 Xming (http://www.straightrunning.com/XmingNotes/)或者 Xmanger等为windows平台的xserver 实现,然后很多工具用起来还挺好用的。当然你也可以在参数里面填一个远程的linux平台的xserver的display给putty作为参数。
详细的说明可以参考一下ssh的文档或和这个网站
http://www.techotopia.com/index.php/Displaying_Ubuntu_Linux_Applications_Remotely_%28X11_Forwarding%29
===================
这样就是不用配置本地的xserver 监听tcp的端口,可能安全性行更好吧(第一种方法xserver采用的 xdmcp协议是不加密的,键盘事件等都可能被别人监控到。)。但需要你能够配置远程机器上的ssh server权限才行。但有的时候远程机器只能telent连接过去,而且有不能装ssh server时,就可以用第一种办法,先配置好本地xserver (ubuntu的要开放tcp连接,windows 的Xming的话也需要xserver启动了吧),然后export DISPLAY环境变量或者用--display参数启动程序就可以了。
==================================
参考资料:
x11 security
=============
index
locking the console
X security and remote X
x11 screenlock applications
---------------------------
kde screensaver
kshutdown
http://kshutdown.sourceforge.net/
lock-keyboard-for-baby
http://csincock.customer.netspace.net.au/lock-keyboard-for-baby.htm
xscreensaver
fedora rpms: xscreensaver-base xscreensaver-extras xscreensaver-gl-extras
- run as a non-root user to use locking feature
note: xfce "lock" button uses xscreensaver
- time: see time.html for details on using xscreensaver for clock
others
~~~~~~~~~~~~~~
control-center
coldspot - not updated since 2002; requires another program such as xscreensaver to lock screen
gnome-screensaver
- runs as a daemon?
xautolock
- not a locker - just runs specified program after specified period
xdg-screensaver
xdg-screensaver lock
- impotent...
xlock
xlockmore
X security
-----------------------
See Xsecurity man page
The X window system allows remote access. By default, X uses TCP/IP at port 6000. If you are on computer B and want to run an X application on computer A but see it's output on computer B, two things are required:
- you need to tell computer B where to send the X11 application's output
- you need to tell computer A how to receive information from computer B
Obviously, you want computer A to discriminate regarding what it allows to be displayed on its X server so that any joe in the world isn't able to send X11 application output to computer A. Obviously, computer B is also interested in not having any old X application from anywhere try and send its output to computer B's X server.
The DISPLAY environment variable
----
- the X server can manage one or more DISPLAYS (generally a combination of monitor, keyboard, and mouse)
- the DISPLAY environment variable defines the name of the display - e.g.,
DISPLAY=:0
DISPLAY=localhost:10.0
- the format is hostname:sequence-number.n
- the hostname is the name of the computer where the X server runs
- the ".n" indicates that we are dealing with the nth screen (a single display can have multiple screens)
- the sequence-number is the display number
The X11 application (the client program relative to the X server) knows which display to connect to by inspecting the DISPLAY variable. For most X applications, you can use the "-display" command-line option to specifically direct the output - e.g.,
xdpyinfo -display localhost:11.0
the X server and authentication
-=-=
The X server doesn't accept connections from any computer. How does the server authenticate connections? First of all, the X server can be started so that it accepts no TCP/IP connections - check if this is the case by
1. the host system (xhost)
- this is relatively insecure - avoid it
2. the magic cookie system (xauth)
xhost
----
This command turns the X authority system on/off for Xserver program. It will also allow users to disable/enable authorization checking from a particular machine. IE: a user can allow anyone on a particular host (often a private workstation) to use his/her display without authorization. By default this command has full authorization enabled, no host in its `authorized' host list
Example:
prompt>> xhost
access control enabled, only authorized clients can connect
dragon
cornet
This means that any program running on either of the machine dragon or
cornet can place windows on your screen without any trouble. If the
program was not run on either of these machines, the user must have
a `authorization password' (See method 2).
Removing a machine
xhost -cornet
Adding a machine
xhost +cornet
Allowing use of your display from any machine (in the world)
xhost +
To return to normal
xhost -
Note, because of the unusal systax of xhost you can't use a
``-display host:0'' option with it, instead use the env command to
set the ``DISPLAY'' environment variable for just that command.
env DISPLAY=host:0 xhost
xauth
-=-=
Xauth will allow access to anyone who knows the "secret". The secret is the 'authorization record' or 'magic cookie'. For server Y to put its client window on computer X, server Y must have computer X's authorization record. The cookies for different displays are stored in ~/.Xauthority (use xauth -v to confirm this). Use xauth list to list the cookies. To use xauth, the X server must be started with the -auth authfile argument (true?).
Enabling Xauth:
- xauth will be enabled on a display when you are using the `xdm' program (the one that displays the initial login window if you're booting into level 5) - xdm will create a file in your home directory called ``.Xauthority''. This file holds a password, key, magic-cookie or X authorization to allow you to access your display regardless of your xhost permission.
- Xauthorization can also be enabled when you start a X session using the ``startx'' program. This involves setting up a .xserverrc file with the appropriate ``-auth {key}'' X server option.
Generating the .Xauthority file:
- normally xdm creates the .Xauthority file but, if not running xdm, you may need to use xauth to create the authority file:
xauth generate displayname protocolname
e.g.,
xauth generate
- see also mkxauth
mkxauth -c <host>
- create a local Xauthority database
xauth
This command allows uses to list/add/remove/copy X authorization passwords from a given (default the users) ".Xauthority" file. This is a binary file and this command is the only real way of reading this file. Also the command ensures that all authority files is only read/writable by the owner of the file, thus insuring file security. Only root can read/write any authority file.
To list this file type (assuming you are on dragon)
prompt>> xauth list
dragon.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 e102ba90f0f55f2108a9ee2526537845
The format of the list is:
# machine auth-type authorization (cookie)
Note: sometimes authorities from old sessions are also present. This is of
no importance as every session has a new authority password generated on
every login.
If you do not have xhost permission (method 1) you MUST have the current authority to the display you wish to access. For example a friend decided to give me access to his display on thorax. He did not however wanted to use xhost as he only wanted to give me permission -- not just anyone on machine I am working on. So he mailed (or other means) his current authority.
thorax.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 3704a0c7fd52c90eabf53892c0ba7ee1
So I then add this to my ``.Xauthority'' file
prompt>> xauth add thorax.cit.gu.edu.au:0 MIT-MAGIC-COOKIE-1 3704a0c..etc
Now I have access to his display regardless of his xhost setup and can do anthing on his display that he can do, untill he (or I) kills the current X session. However unless I am in the same room it is difficult for me to actually see what I am doing without some sort of `spy' program, and I definatly do not have control over the mouse (physical, the cursor I could control) or the keyboard.
WARNING: If someone has permission to access your display (via either
xhost or xauth) they can not only open windows, but can also look at your
display, or kill various windows, and terminate your current session! See
Below for good reasons why you shouldn't allow this. The most common
reason for allowing such access seems to be for X window games.
troubleshooting
====
"unable to open display"
- is the X server running on the remote machine or is it in console mode w/everyone logged out?
- if not try rebooting into level 5 (with xdm running)
- is the X server accepting remote connections?
- check if your firewall is blocking connections
Systematically:
1. Verify X11 is working on the local host:
export | grep DISPLAY
xdpyinfo (should give no errors)
2. Verify that X11 is working for clients on the remotehost via ssh forwarding:
me@localhost$ ssh remotehost
[...]
me@remotehost$ echo $DISPLAY # check DISPLAY is set for X11 forwarding
localhost:21.0
me@remotehost$ xdpyinfo # check that X11 forwarding works - shouldn't give any errors
me@remotehost$ # test with simple app
===================
How to Kill and Restart X Server
A GUI is a very complex piece of software and there could be any number of reasons why it would lock up on you. If you need to kill your x server and then restart it, here are some tips:
Killing X server via Command
Type “init 3″ in your terminal and that should kill x server. If it doesn’t find the command, then switch to the root user by typing “su -” (you will need to know the root password).
Restarting X server
Simply use the keyboard combination CTRL+ALT+BACKSPACE. Some times this will help, but this combination will explicitly restart the X server.
Working with a Console
If the previous keyboard combination did not work then try CTRL+ALT+F1. This will not kill X server, it will simply open a full screen console. I believe Red Hat and Fedora Core have F1-F6 as options. If you want to switch back to a GUI environment use the keyboard combination CTRL+ALT+F7.
Processes
Once you’re in the full screen console mode, you will have to use the kill command to close X server. Unfortunately; you can’t simply type in “kill xserver”. You’ll have to find it’s process ID, using the ps command. The ps command displays a list of the current processes running on the machine. There are tons of options for this command, use man ps to find which option works for your situation.
Once you found the process ID for the process you want to end, type in kill {process_id}. Let’s assume your process id is 1344. You will type kill 1344 and presto that process is no longer functioning.
Init Command
If you want to get out of the full screen console and into a bonafied console environment, use the init command.
* init 1 - kills all processes and loads the user into a full console.
* init 5 - runs the multi-user and GUI scripts in rc.d/rc5, which will start your login manager and put you back into a GUI environment.
Starting X server
Once you have X server killed, or no longer running - you can either type in init 5 or startx to get X server up and running again. If all else fails, simply reboot.