SSH X11无法正常工作


15

我有一台家用和办公计算机,该家用计算机具有静态IP地址。

如果我从工作计算机SSH切换到家用计算机,则SSH连接有效,但不显示X11应用程序。

在我/etc/ssh/sshd_config家里:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

在工作中,我尝试了以下命令:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

/etc/ssh/ssh_config在工作:

Host *
ForwardX11 yes 
ForwardX11Trusted yes

~/.ssh/config在工作:

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

~/.Xauthority在工作:

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

~/.Xauthority在家

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

但这不起作用

在建立到家庭的ssh连接之后:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

iptables在家中使用,但已允许使用端口22。根据我所读的内容,这就是我所需要的。

UPD。-vvv

...
debug2:回调启动
debug2:x11_get_proto:/ usr / bin / xauth列表:0 2> / dev / null
debug1:请求使用身份验证欺骗的X11转发。
debug2:通道1:请求x11-req确认1
debug2:client_session2_setup:ID 1
debug2:fd 3设置TCP_NODELAY
debug2:通道1:请求pty-req确认1
...

尝试启动时kate

debug1:client_input_channel_open:ctype x11 rchan 2 win 65536最大16384
debug1:client_request_x11:来自127.0.0.1 55486的请求
debug2:fd 8设置O_NONBLOCK
debug3:fd 8是O_NONBLOCK
debug1:渠道2:新[x11]
debug1:确认x11
debug2:X11连接使用不同的身份验证协议。
X11连接由于身份验证错误而被拒绝。
debug2:X11拒绝了2个i0 / o0
debug2:通道2:读取失败
debug2:通道2:close_read
debug2:通道2:输入打开->排空
debug2:通道2:ibuf为空
debug2:通道2:发送eof
debug2:通道2:输入漏极->关闭
debug2:通道2:写入失败
debug2:通道2:close_write
debug2:通道2:输出打开->关闭
debug2:X11关闭了2个i3 / o3
debug2:通道2:发送关闭
debug2:通道2:rcvd关闭
debug2:通道2:已死
debug2:通道2:垃圾收集
debug1:通道2:空闲:x11,nchannels 3
debug3:通道2:状态:以下连接已打开:
  #1客户端会话(t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  #2 x11(t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

#与上述相同重复约7次

凯特:无法连接到X服务器localhost:10.0

UPD2 请提供您的Linux发行版和版本号。
您是否正在为X或您自定义的其他内容使用默认的GNOME或KDE环境?

azat:〜$ kded4-版本
Qt:4.7.4
KDE开发平台:4.6.5(4.6.5)
KDE守护程序:$ Id $

您是从终端窗口直接在命令行上调用ssh吗?
您正在使用哪个终端?xterm,gnome-terminal还是?
您是如何启动在X环境中运行的终端的?从菜单?热键?要么 ?

从终端仿真器“ yakuake”
手动按Ctrl + N并编写命令

您可以从ssh -X失败的同一终端窗口中运行xeyes吗?

`xeyes`-未安装
但是`kate`或其他kde应用正在运行

您是否以与登录X会话相同的用户身份调用ssh命令?
From the same user

UPD3

我还下载了ssh源代码,并使用debug2()write编写了为什么报告版本不同的报告。
它看到一些cookie,其中一个是空的,另一个是MIT-MAGIC-COOKIE-1

Answers:


21

ssh X转发不起作用的原因是因为我有一个/etc/ssh/sshrc配置文件。

sshd(8)手册页的末尾指出:

如果~/.ssh/rc存在,运行它;否则/etc/ssh/sshrc,运行它;否则运行xauth

因此,我将以下命令添加到/etc/ssh/sshrc服务器端(同样从sshd手册页):

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

而且有效!


您是在客户端还是在服务器端?
alfonx 2013年

在服务器端。(/ etc / ssh / sshrc在连接客户端时执行)
azat 2013年

2

每当您遇到ssh麻烦时,您应该做的第一件事就是运行带有-v选项的客户端,以提供该输出供他人检查:

ssh -v user@somewhere

我将猜测问题出在您的本地系统上。您如何调用ssh命令?您是否在外壳中手动运行它?还是将其作为脚本的一部分执行?无论哪种情况,您都需要确保本地系统的DISPLAY环境设置正确。它也需要在远端设置正确,以及,但该值会有所不同,在远程侧比本地端。

从您撰写的内容来看,似乎已在远程主机上正确设置了它(并且通过扩展,X11转发已由ssh正确设置了)。在远程系统上,您具有:

$ echo $DISPLAY
localhost:10.0

在本地显示的是什么?通过回显值以及从该外壳启动X应用程序,这应该很容易检查您是否在外壳中……当然,您始终可以将尊贵的人xeyes用于这种测试!:)

另一方面,如果要从脚本调用ssh命令或将其附加到热键,则它可能不会继承您期望的环境,因此DISPLAY可能根本不会设置本地的环境变量。

另外,由于听起来您一直在摆弄.Xauthority文件,因此您可能希望将其完全删除,然后退出X会话并重新登录,以便它会自动重新创建它。很少有需要与您混为一谈的.Xauthority,因此尝试这样做可能只是一种绝望的措施而无济于事。

您应该在本地看到的是:

$ echo $DISPLAY
:0.0

在正确配置的系统上,如果打开外壳,则无需手动进行设置,它应从启动外壳的环境中继承。但是我看到了窗口管理器/热键配置不能正确处理环境变量继承。如果您正在运行linux系统gnome-sessionkde-session用于从中启动shell或脚本,那么应该按照Ubuntu文档中有关环境变量继承的说明正确设置X会话环境变量

当父进程创建子进程时,例如,当我们从终端运行“ gedit”命令并且“ bash”(父进程)创建“ gedit”(子进程)时,子进程将继承所有环境变量,并且父进程具有的值。

...

注意:在Gnome图形桌面环境中,gnome-session是桌面上运行的所有进程的父进程。这个事实(以及继承原则)是我们使用环境变量强大影响桌面操作的能力的关键。KDE中的等效过程是kde-session。

更新

感谢您发布来自的输出ssh -vvv。在这种情况下,来自-vvvvs 的额外详细程度-v会有所帮助。调试输出告诉我X11转发已正确设置:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

但是:0第一行中的导致我相信,在调用ssh的方式上,本地仍然存在配置错误。在许多系统中的默认值DISPLAY:0.0,没有:0。您是否DISPLAY在调用ssh命令之前自行设置了手动值?

此时,有关本地系统以及如何调用ssh命令的更多信息将很有帮助。

  • 请提供您的Linux发行版和版本号。
  • 您是否在X或您自定义的其他内容上使用默认的GNOME或KDE环境?
  • 您是从终端窗口直接在命令行上调用ssh吗?
  • 您正在使用哪个终端?xterm,gnome-terminal还是?
  • 您是如何启动在X环境中运行的终端的?从菜单?热键?要么 ?
  • 您可以xeyesssh -X失败的同一终端窗口运行吗?
  • 您是否以与登录X会话相同的用户身份调用ssh命令?

最后一项很重要。如果您以其他用户身份运行ssh(例如,如果您打开了根终端窗口而不是用户终端窗口),那么即使您进行了明确设置,也将遇到此问题,DISPLAY=:0因为您没有权限默认情况下以另一个用户(甚至以root用户身份)连接到X服务器。


更新问题正文
zat 2012年

我添加了一个新的UPDATED部分,要求更多信息以帮助进一步调试。
aculich 2012年

我没有t set 手动显示。实际上,我认为我理解为什么它不起作用,因为X -nolisten在本地计算机上
azat 2012年

-nolisten与这个问题无关。就X而言,它对您的远程ssh连接一无所知。对于X,它看起来像任何其他本地程序。
aculich 2012年

1
sshd如果问题出在服务器端,也可以以额外的冗长性在前台启动。
0xC0000022L 2012年

1

您的配置似乎还可以,但是请按照Agemen的建议尝试“ ssh -X home”。

另外,如果其他所有方法均失败,请尝试以下操作:

在从工作场所SSH到家用计算机后,在“家用”上键入:

xauth list

然后,在“工作”上,键入

xauth

这将给您一个“ xauth>”提示。在这里,键入“ add”,然后复制粘贴“ xauth list”的输出,一次仅一行(每行以“ add”开头)。例如:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

让我们知道


我已经尝试过了ssh -X home(写在帖子中)。关于xauth,我明天尝试。
2011年

我尝试了xauth list & xauth add,但仍然行不通
2011年

我已经通过xauth add azat/unix:10 MIT-MAGIC-COOKIE-1 ad01c582768c832ff591277b27863bc7(因为$ DISPLAY = localhost:10.0)添加了该记录,如果可以的话
2011年

-1

我不清楚您是要在本地显示器上显示远程应用程序(work),还是要在远程系统上显示它们home

在第一种情况下,我认为ssh -X host应该足够了,而无需使用xhost。

在第二种情况下,您需要使用xhost的系统是home,而这还不够,您还需要导出显示变量。

xhost +work
export DISPLAY=:0.0

我不确定您要做什么...而且我不知道您的系统和我的第一方之间存在什么差异,而另一方面您所需要的确切配置(如我不是专家^ _ ^)。希望它会在某些方面对您有所帮助,因为这种配置对我也很有效。


我已经尝试过了ssh -X home(写在帖子中)。是的,我想在本地显示器上显示远程应用程序。
2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.