尝试通过SSH进入主机时，我收到了以下消息xauth：

/ usr / bin / xauth：锁定授权文件/home/sam/.Xauthority中的超时

注意：我试图通过SSH连接远程显示X11 GUI，所以我需要xauth能够创建一个$HOME/.Xauthority成功文件，但是正如该消息所指示的那样，显然不是。

尝试运行任何基于X11的应用程序，例如，xeyes收到以下消息：

$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0

我该如何解决这个问题？

strace在远程系统上运行xauth发生故障将显示发生故障的原因xauth。

例如

$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0

所以xauth正在尝试打开一个文件，它已经存在。罪魁祸首文件是/home/sam/.Xauthority-c。我们可以确认此文件在远程系统上是否存在：

$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-l

解决方法

事实证明。这些文件是的锁定文件.Xauthority，因此只需删除它们即可解决此问题。

$ rm -fr .Xauthority-*

删除文件后，退出SSH连接，然后重新连接。这将允许xauth重新运行成功。

$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$

现在，我们可以运行xauth listX11应用程序而没有问题了。

$ xauth list
blackbird/unix:10  MIT-MAGIC-COOKIE-1  cf01f793d2a5ece0ea58196ab5a7977a

图形用户界面

$ xeyes

解决问题的替代方法

我碰到了一篇标题为xauth：锁定授权文件.Xauthority [linux，ssh，X11]中的错误的文章，其中提到了使用xauth -b来破坏所有可能徘徊的锁定文件。xauth的手册页似乎支持了这一点：

 -b      This option indicates that xauth should attempt to break any
         authority file locks before proceeding.  Use this option only to
         clean up stale locks.

参考文献

• 处理xauth“锁定授权文件中的错误”错误

问题的根源可能是您在$ HOME目录中没有写权限。

这就是为什么我收到此消息的原因：

/ usr / bin / xauth：锁定授权文件/home/fooftp/.Xauthority中的超时

这是我检查权限的方法：

fooftp@for-fun-work:~> ls -l .Xauthority 
-rw-r--r-- 1 fooftp fooftp 1 Sep 14  2015 .Xauthority
# Conlusion: I can write this file: ok

fooftp@for-fun-work:~> rm .Xauthority
rm: cannot remove '.Xauthority': Permission denied
# Conlusion: strange ... I can't delete it 

fooftp@for-fun-work:~> id
uid=1001(fooftp) gid=1000(fooftp) groups=1000(fooftp)
# Conlusion: Yes, I am user fooftp

fooftp@for-fun-work:~> ls -ld .
dr-xr-xr-x 14 fooftp fooftp 4096 Sep 14  2015 .
# Conlusion: Bug found :-)
# The permissions should be "rwx" for you.

如果这是问题所在，则需要确保您具有对$ HOME的写入权限：

chmod u+rwX $HOME

在弄清楚这个问题之前，我对困扰我的问题还有另一个答案。我后来发现，问题是Fedora OS及其衍生版本中的错误。如果问题不是所接受的答案所表明的，和/或您不在Fedora，RedHat，Korora等上，那么这将对您没有帮助。

问题

正如用户slm所说，运行strace可以为您提供问题的指示，但是在这种特定的错误情况下，输出是不同的：

$ strace xauth list
  ...
  stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
  ...

需要明确的是，这表明EACCES返回了代码，但该代码被拒绝。这不同于用户slm的问题，后者有EEXIST返回代码，这意味着文件存在。因此，对于EACCES返回代码，显然您要检查的第一件事是：是否设置了我的主目录权限，以便能够写到主目录？您应该首先验证自己的用户在主目录中是否具有写标志。如果这样做，那么您可能是下面描述的错误的受害者。

错误

通过几次Google搜索，我终于找到了一个类似问题的人，这使我想到了Fedora错误报告。对于那些关心阅读的人：https : //bugzilla.redhat.com/show_bug.cgi?id=772992

解决方法

该问题的解决方法：

#verify you're not crazy
$ xauth list
  /usr/bin/xauth:  timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority 
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit

当您重新登录SSH时，这应该没问题，您应该能够再次成功传输X会话。

编辑（和其他替代解决方法）：

为了尽可能完整，其他用户确实在错误报告中指出上述修复对他们不起作用-它确实对我有用。解决该问题的另一种尝试是（我没有亲自验证此解决方法）：

# setsebool -P use_nfs_home_dirs 1

另一个人提到了一些有关GDM的知识，我对此一无所知。如果这与您有关，我建议您阅读他在BugZilla中的帖子，看看他的评论对您来说有没有意义。

SELinux配置是签出的第一件事，它具有...

*/usr/sbin/sestatus*

要么

*/usr/sbin/sestatus -v*

如果SELinux配置设置为“ Enforcing”，则可能导致“ xauth”问题。

 /usr/sbin/setenforce 0

您可以将其临时设置为“ permisive”模式，如下所示（以便能够将此问题排除为问题的根本原因）。

然后按照SELinux教程进行适当的配置，或者如果您喜欢其他安全方法，则将其禁用（例如，通过在RHEL v.6中编辑/ etc / selinux / config配置文件）