我有一个烦人的问题。
当我通过 SSH 登录到特定主机时,消息
X11 connection rejected because of wrong authentication.
Run Code Online (Sandbox Code Playgroud)
大约每分钟发生 3 次看似随机的。我不知道它来自哪里。
实际上,X11转发甚至没有任何小问题,它就像一个魅力。但是这条消息不断出现,它让我发疯。
有谁知道如何摆脱它?
无论我来自哪里,我都面临这个问题,它发生在我的 Gnome 桌面以及使用 PuTTY、MobaXterm、Cygwin 等的 Windows 系统中。
经过一番折腾,我发现原因是监控代理(check_mk)。这会检查正在运行的任务的一些运行时参数,消息每次都会出现,当这个代理从监控系统被触发时,正是在检查 PostgreSQL 状态时。这个过程似乎试图打开一个 X11 连接,但失败了。当它尝试使用我转发的 X11 会话时,该消息会被吐到我的终端会话中。
有没有办法完全禁用此消息?
Ant*_*ölä 34
我有一个有趣的版本,xeyes和xlogo可以工作,但chromium不行。
这是使用 snap 安装 chromium 的一个功能。
快速解决:
export XAUTHORITY=$HOME/.Xauthority
chromium
Run Code Online (Sandbox Code Playgroud)
查看更多:
https://unix.stackexchange.com/a/709789/12207
dev*_*ull 28
运行 df 并确保您有足够的磁盘空间,如果磁盘空间不足,请从系统中删除不必要的文件:
$ df -h
Run Code Online (Sandbox Code Playgroud)
如果对文件系统施加了配额,请检查您是否没有超过配额:
$ quota -s
Run Code Online (Sandbox Code Playgroud)
运行以下命令以查找 ownweship:
$ ls -l ~/.Xauthority
Run Code Online (Sandbox Code Playgroud)
运行 chown 和 chmod 来修复权限问题[用您的实际用户名和组名替换 user:group]:
$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority
Run Code Online (Sandbox Code Playgroud)
确保 sshd_config 文件中存在以下行:
$ grep X11Forwarding /etc/ssh/sshd_config
Run Code Online (Sandbox Code Playgroud)
示例输出:
X11Forwarding yes
Run Code Online (Sandbox Code Playgroud)
如果 X11 已禁用,请将以下行添加到 sshd_cofin 并重新启动 ssh 服务器:
X11Forwarding yes
Run Code Online (Sandbox Code Playgroud)
确保您的本地 ssh_config 具有以下几行:
Host *
ForwardX11 yes
Run Code Online (Sandbox Code Playgroud)
最后,登录远程服务器并从 Mac OS X 或 Linux 桌面系统运行 X11,如下所示:
ssh -X user@remote-host.com
Run Code Online (Sandbox Code Playgroud)
信用信息属于这里:http : //www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-authentication/
希望有帮助。
我遇到了同样的问题,这对我有用。(注意:这不是我的解决方案,但由于我努力找到它,所以我将其重新发布在这里。您可以在此处和此处找到原始解决方案)
echo $DISPLAY
这应该显示您当前的 X11 显示屏
xauth list
如果控制台上没有打印任何内容,则意味着 ssh 没有在本地显示上正确自动生成 X11 授权 cookie
xauth add $DISPLAY - `mcookie`
这会将您显示器的授权 cookie 添加到 xauth
xauth list
检查您的显示器是否已添加
xauth nextract ~/xcookie $DISPLAY
exit
在本地:scp user@remote:~/xcookie ~/xcookie
在本地:xauth nmerge ~/xcookie
最后再次登录远程服务器应该就解决了。
可能是不受信任的 X11 转发超时。使用ForwardX11Timeout
具有较长超时的选项可能会有所帮助,如https://bugzilla.mindrot.org/show_bug.cgi?id=1718中的建议(我过去遇到过这个问题,但是 IIRC,在升级后它消失了)。