web-dev-qa-db-ja.com

xauthから次のメッセージが表示されるのはなぜですか：「ロック認証ファイル/home/<user>/.Xauthorityでタイムアウト」？

ホストにSSH接続しようとすると、xauthから次のメッセージを受け取りました。

/ usr/bin/xauth：ロック権限ファイル/home/sam/.Xauthorityのタイムアウト

注： SSH接続を介してX11 GUIをリモート表示しようとしたため、xauthを作成して$HOME/.Xauthorityファイルは正常に送信されましたが、そのメッセージが示していたように、明らかにそうではありませんでした。

xeyesなどのX11ベースのアプリを実行しようとすると、次のメッセージが表示されました。

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

この問題を解決するにはどうすればよいですか？

x11remote-managementxauth
33
slm

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 listおよびX11アプリケーションを問題なく実行できるようになりました。

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

GUI

$ xeyes

ss#1

問題を解決する別の方法

xauth：Authorization file .Xauthority [linux、ssh、X11]のロックでエラーが発生しました ハングアップしている可能性のあるロックファイルを破壊するためのxauth -bの使用について言及しています。 。 xauthのmanページはこれを裏付けているようです：

 -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.

参考文献

41
slm

問題の根本的な原因として、$ 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
9
guettli

問題を理解する前に私を悩ませた質問に対する別の答えがあります。この問題は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戻りコードであることを示しています。これは、ファイルが存在することを意味するEEXIST戻りコードがあったユーザーslmの問題とは異なります。したがって、EACCESの戻りコードの場合、最初に確認するのは明らかに、ホームのアクセス許可が設定されているので、ホームディレクトリに書き込むことができるのでしょうか。最初に、自分のユーザーのホームディレクトリに書き込みフラグがあることを確認する必要があります。その場合、以下に説明するバグの被害者である可能性があります。

不具合

いくつかのグーグル検索を介して、私は最終的に同様の問題を持つ誰かを見つけることができました、そしてそれは私を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で彼の投稿を読んで、彼のコメントがあなたに何か意味があるかどうかを確認することをお勧めします。

3
searchengine27

私にとって、2つのステップ：

  1. 新しいユーザーを作成しました。新しいユーザーとしてログインし、fehなどのコマンドを使用してX転送を試みます。
  2. 古いユーザーとして再度ログインし、新しいユーザーの〜/ .Xauthorityファイルを使用して古い〜/ .Xauthorityを置き換えます。
0
Cheng

SELinux構成は、最初にチェックアウトするものです。

*/usr/sbin/sestatus*

または

*/usr/sbin/sestatus -v*

SELinux設定が"Enforcing"に設定されている場合、"xauth"の問題が発生している可能性があります。

 /usr/sbin/setenforce 0

次のように、暫定的に"permisive"モードに設定できます（この問題を問題の根本原因として除外できるようにするため）。

次に、SELinuxチュートリアルに従って適切な構成を配置するか、別のセキュリティメソッドを使用する場合は無効にします（たとえば、RHEL vで/ etc/selinux/config構成ファイルを編集して）。 6）

0
fjcobas