本文主要是介绍X-Security X的安全控制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
X-Security
X-Window系统的’访问控制(access control)’功能由X-Security来定义,X-Server端可配置基于IP级别的验证和基于共享key的验证.
确认当前X-Server的’访问控制’功能已开启
xhost配置的是当前终端环境变量DISPLAY所指向的X-Server.所以配置前先确认当前环境变量中的DISPLAY值
rock@rock-ubuntu17:~$ echo KaTeX parse error: Expected 'EOF', got '#' at position 12: DISPLAY :1 #̲显示当前访问控制的状态,和xh… xhost
access control enabled, only authorized clients can connect
SI:localuser:rock
该输出表示访问控制功能已开启,只允许通过IP验证 或 通过共享密钥验证的才能访问X-Server服务
#关闭访问控制. 不验证xhost和xauth
rock@rock-ubuntu17:~$ xhost +
access control disabled, clients can connect from any host
#开启访问控制. 验证xhost和xauth
rock@rock-ubuntu17:~$ xhost -
access control enabled, only authorized clients can connect
基于IP验证
一个Displayer(X-Server)对应一个xhost列表
只需在X-Server端配置
X-Client请求接入时, X-Server验证X-Client的IP是否在放行列表中,不在则拒绝接入
使用xhost维护
#指定配置Displayer1
rock@rock-ubuntu17:~$ export DISPLAY=:1
#允许10.211.55.2上的X-Client接入Displayer1
rock@rock-ubuntu17:~$ xhost + 10.211.55.2
10.211.55.2 being added to access control list
#显示Displayer1上的IP放行列表
rock@rock-ubuntu17:~$ xhost
access control enabled, only authorized clients can connect
INET:10.211.55.2
SI:localuser:rock
以上设置重启失效,永久设置需要写入到对应的配置文件:/etc/X[n].hosts. n为X-Server显示器ID.即:
/etc/X0.hosts: 配置Displayer0的放行列表
/etc/X1.hosts: 配置Displayer1的放行列表
基于预共享密钥验证
一个X-Server关联一个Xauthority文件, 一个Xauthority文件可包含多个Displayer的预共享密钥. X-Server只使用他所关联的Xauthority文件里自身Displayer的密钥记录
需要在X-Server端和X-Client端配置一致的密钥
X-Client接入时带上目标Displayer的密钥,X-Server验证该密钥是否与本地Xauthority文件里配置的一致,不一致则拒绝
使用xauth维护
xauth默认配置的是环境变量XAUTHORITY所指向的Xauthority文件或用户家目录的.Xauthority(当环境变量’XAUTHORITY’不存在时); 可以用-f参数显式指定
在X-Server端为Displayer2生成密钥
rock@rock-ubuntu17:~$ xauth
Using authority file /run/user/1000/gdm/Xauthority
#生成DISPLAY=:2显示器的共享key, '.'表示使用机制’MIT-MAGIC-COOKIE-1’明文共享密钥
xauth> generate :2 .
authorization id is 572
#查看当前显示器共享key列表
xauth> list
rock-ubuntu17/unix:1 MIT-MAGIC-COOKIE-1 5d8f557af058440ef69d6aaa665c91fb
rock-ubuntu17/unix:2 MIT-MAGIC-COOKIE-1 578f3bb50f08cd4831277cc4397a2611
xauth> exit
Writing authority file /run/user/1000/gdm/Xauthority
在X-Client端配置对端Displayer2的密钥
#添加目标Displayer的访问密钥
root@dld:~# xauth add 10.211.55.5:2 . 578f3bb50f08cd4831277cc4397a2611
#配置当前终端使用上步骤的远端Displayer2
root@dld:~# export DISPLAY=10.211.55.5:2
root@dld:~# xclock
如果要编辑指定的Xauthority文件,则:
rock@rock-ubuntu17:~$ xauth -f /root/.Xauthority
X-Server执行时可使用’-auth [auth-file]’选项指定使用的Xauthority文件
rock@rock-ubuntu17:~$ sudo X :1 vt5 -auth /run/user/121/gdm/Xauthority
协议
NAT-sensitive(NAT敏感)
NAT敏感 通常是因为协议的应用报文中带有对端的IP信息, 对端在处理应用逻辑里需要依赖这IP信息. 然而对端在NAT环境后面(即做了DNAT, 外网IP映射为内网IP), 本端是不知道你是做了DNAT的, 所以带的对端的IP是对端的外网IP, 这时对端解释到的IP信息是外网IP, 但他应用逻辑是用内网IP的, 因此导致应用逻辑上的混乱
X-Server与X-Client之间的远程通信使用TCP方式, 在实际测试中发现X-Server和X-Client在同一个局域网内才能连接成功, X-Client连接NAT后的X-Server的话是不能成功的. 看来这协议是’NAT敏感’的. 解决方法通常是使用SSH隧道
还有一个内容本文章没提及, 那就是XDM(X-Display-Manager), 他使用的是XDMCP协议, 走UDP177端口. 以后有机会再补充这块内容
结合SSH隧道运行远端GUI应用
为解决刚说的’NAT敏感’问题. 我们常常使用SSH隧道上的端口转发功能来绕过问题, 其原理图如下:
ssh_tunnel
远端上的X-Client应用程序访问其本地SSH-Server开启的转发监听端口PORT1, SSH-Server将其在Port1在监听接入的数据通过已经建立好连接的SSH隧道转发到我们本地的SSH-Client, SSH-Client再将数据转发到本地X-Server所监听的TCP端口PORT2
以PORT1为6010, PORT2为6002为例, 其SSH隧道建立及开启转发功能的连接命令为:
ssh -R 127.0.0.1:6010:127.0.0.1:6002 user@remotehost
ssh有个简洁的-X参数能自动根据环境配置以上转发参数及远端SSH终端的DISPLAY环境变量. 可以自行翻阅文档查看详情, 这功能需要在SSH-Server开启’X11 Forwarding’选项
这样一来就避开了’NAT敏感’的问题, 从X-Client看来他只是访问本地的X-Server, 从X-Server看来他只是接入本地的X-Client, 所有X层面上看到的IP都是127.0.0.1
同时这个做法避开了X-Security的f远程主机验证,因为都认为是本地主机的访问,只需允许本地访问即可
应用案例
本地MAC端运行远端GUI应用
下面演示使用XQuartz结合SSH的’Forwarding’运行远端GUI
先在本地运行XQuartz:
配置允许网络客户端接入(开启使用TCP方式):
xquartz_conf
关闭XQuartz, 重新打开XQuartz. 此时已发现tcp6000端口已经在监听:
xquartz_listen
允许本地主机访问XQuartz. XQuartz默认没允许本机IP访问
xhost + 127.0.0.1
xquartz_xhost
用ssh的’-R’选项在SSH会话上开启隧道端口转发功能:
意思为将本地XQuartz的X-Server端口tcp6000映射到远端本地上的tcp6010
root@test:~# ssh -R 127.0.0.1:6010:127.0.0.1:6000 user@remotehost
xquartz_ssh
配置远程终端的DISPLAY环境变量
root@test:~# export DISPLAY=:10
如步骤2截图
执行GUI
root@test:~# xterm&
root@test:~# xeyes
使用X11-Forwarding(即’ssh -X user@host’)操作会比较简单, 其实他自动做的事的步骤就是以上说的
本地Ubuntu端运行远端GUI应用
下面演示使用Xorg结合SSH的’Forwarding’运行远端GUI
先在本地的tty5运行Xorg
当前在tty2:
rock@ubuntu17:~$ sudo X :2 vt5 -listen tcp -retro&
tty5:
x_blank
ctrl+alt+F2回到tty2, 确认已经在本地开启Displayer2对应是tcp6002监听:
用ssh的’-R’选项在SSH会话上开启隧道端口转发功能:
ssh -R 127.0.0.1:6010:127.0.0.1:6002 user@remotehost
确认SSH-Server已为我们启动端口转发功能:已开启tcp6010监听
配置远程终端的DISPLAY环境变量, 执行GUI
配置DISPLAY=:10指向SSH启动的转发端口6010:
ctrl+alt+F5 :
最终已转发到我们本地的6002端口:
xorg_xclock
使用X11-Forwarding(即’ssh -X user@host’)操作会比较简单, 其实他自动做的事的步骤就是以上说的
本地Windows端运行远端GUI应用
下面演示使用Xmanager套件结合SSH的’X11 Forwarding’运行远端GUI
先在本地运行X-Server:
现在X-Server已启动, 为Displayer0, 监听tcp6000
接下来运行Xshell, 配置远端会话属性, 开启SSH隧道中的’转发X11’选项:
注意: SSH服务端也需要开启’X11 Forwarding’选项. 不开的话Xshell配置隧道中用’TCP/IP转移’也行, 原理就是前面所说的
登录SSH,并执行GUI, 相应的UI已经在windows本地显示出来:
可看到’X11 Forwarding’已经帮我们终端配置好DISPLAY环境变量了
远端的SSH Server在本地也开启的相应的tcp6015监听, 用于隧道上的端口转发
这篇关于X-Security X的安全控制的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
