Tại sao tôi nhận được tin nhắn này từ xauth: Thời gian chờ trong khóa quyền hạn tập tin /home/<user>/.X mượtity?


32

Trong khi thử SSH vào máy chủ, tôi nhận được thông báo sau xauth:

/ usr / bin / xauth: hết thời gian trong việc khóa tệp thẩm quyền /home/sam/.Xmasterity

LƯU Ý: Tôi đã cố gắng hiển thị từ xa GUI X11 thông qua kết nối SSH vì vậy tôi cần xauthcó thể tạo $HOME/.Xauthoritytệp thành công, nhưng như thông báo đó đã chỉ ra, rõ ràng là không.

Nỗ lực chạy bất kỳ ứng dụng dựa trên X11 nào, chẳng hạn như xeyesđược chào đón với thông báo này:

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

Làm thế nào tôi có thể giải quyết vấn đề này?


1
Tôi thấy trang này hữu ích vì sự cố của tôi là do selinux đang ở chế độ thực thi, điều này đã ngăn không cho tệp được tạo ở vị trí đầu tiên: twiki.cern.ch/twiki/bin/view/CLIC/LCDTroubleSh Boot
Gav Reichel

Câu trả lời:


39

Chạy một stracehệ thống từ xa mà xauthkhông thành công sẽ cho bạn thấy những gì vấp ngã xauth.

Ví dụ

$ 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

Vì vậy, xauthđang cố gắng để mở một tập tin và nó đã tồn tại. Các tập tin thủ phạm là /home/sam/.Xauthority-c. Chúng tôi có thể xác nhận sự hiện diện của tệp này trên hệ thống từ xa:

$ 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

Cách khắc phục

Hóa ra. Các tệp đó là các tệp khóa .Xauthority, vì vậy chỉ cần loại bỏ chúng sẽ giải quyết vấn đề.

$ rm -fr .Xauthority-*

Với các tệp đã bị xóa, thoát khỏi kết nối SSH và sau đó kết nối lại. Điều này sẽ cho phép xauthchạy lại thành công.

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

Bây giờ chúng tôi có thể chạy xauth listcác ứng dụng và X11 mà không gặp sự cố.

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

GUI

$ xeyes

                                              ss # 1

Phương pháp thay thế để giải quyết vấn đề

Tôi đã xem qua bài đăng này có tiêu đề: xauth: lỗi trong việc khóa tệp thẩm quyền .Xmasterity [linux, ssh, X11] trong đó đề cập đến việc sử dụng xauth -bđể phá vỡ bất kỳ tệp khóa nào có thể bị treo xung quanh. xauthTrang người đàn ông dường như sao lưu điều này:

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

Tài liệu tham khảo


1
Bạn có biết những gì gây ra những tập tin khóa bị bỏ lại?
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles - không tôi có cùng suy nghĩ. Tôi đã xóa chúng và sau đó nghĩ rằng, tôi nên cố gắng đi sâu vào những gì đang kiểm soát chúng bằng cách sử dụng lsof. Tôi đã nhìn thấy chúng trước đây nhưng không thể nhớ nơi. Tôi nghĩ rằng bạn và tôi đã thảo luận về họ tại một thời điểm trước đó nhưng không thể tìm thấy bất kỳ đề cập nào về họ trên trang web.
slm

1
Bạn có thể cần sửa các vấn đề của Selinux trước khi xóa các tệp thẩm quyền. Xem froebe.net/blog/2015/01/20/ cường
MrMas

Trong trường hợp của tôi, tệp và thư mục có chủ sở hữu không chính xác (sau khi sao chép thư mục chính của người dùng sang máy tính khác).
Ken Sharp

Trong trường hợp của tôi, các quyền đối với thư mục / home / user được root:rootthay thế user:user. Đã sửa bởi chown user:user /home/user.
0andriy

8

Nguyên nhân của vấn đề có thể là bạn không có quyền ghi trong thư mục $ HOME.

Đó là lý do tại sao tôi nhận được tin nhắn này:

/ usr / bin / xauth: hết thời gian trong việc khóa tệp thẩm quyền /home/fooftp/.Xmasterity

Đây là cách tôi kiểm tra sự cho phép:

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.

Nếu đây là vấn đề, thì bạn cần chắc chắn rằng bạn có quyền ghi vào $ HOME:

chmod u+rwX $HOME

3

Tôi có một câu trả lời khác cho câu hỏi làm tôi bối rối trước khi tôi tìm ra vấn đề. Vấn đề là một lỗi trong Fedora OS và nó là dẫn xuất, như sau này tôi đã tìm ra. Nếu vấn đề không được chỉ ra bởi câu trả lời được chấp nhận và / hoặc bạn không thuộc Fedora, RedHat, Korora, v.v., thì điều này sẽ không giúp bạn.

Vấn đề

Như slm người dùng đã nói, việc chạy strace sẽ cho bạn một dấu hiệu của vấn đề, nhưng trong trường hợp lỗi cụ thể này, đầu ra thì khác:

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

Để rõ ràng, điều này nói rằng mã trả về EACCES, quyền bị từ chối. Điều này khác với vấn đề của người dùng, trong đó anh ta có mã trả về EEXIST, có nghĩa là Tệp tồn tại. Vì vậy, đối với mã trả về EACCES, rõ ràng điều đầu tiên bạn kiểm tra là: các quyền của nhà tôi có được thiết lập để tôi có thể ghi vào thư mục chính của mình không? Bạn nên xác minh rằng bạn có cờ ghi trên thư mục chính của bạn cho người dùng của riêng bạn trước. Nếu bạn làm như vậy, thì bạn có thể là nạn nhân của lỗi được mô tả dưới đây.

Con bọ

Thông qua một vài tìm kiếm trên google, cuối cùng tôi cũng có thể tìm thấy ai đó có vấn đề tương tự, và nó đã dẫn tôi đến báo cáo lỗi của Fedora. Dành cho những bạn quan tâm để đọc về nó: https://ormszilla.redhat.com/show_orms.cgi?id=772992

Cách giải quyết

Cách giải quyết cho vấn đề:

#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

Khi bạn SSH trở lại, nó sẽ ổn vào thời điểm này và bạn sẽ có thể chuyển thành công phiên X của mình một lần nữa.


EDIT (và các giải pháp thay thế khác):

Để hoàn thiện nhất có thể, những người dùng khác đã nêu trong báo cáo lỗi rằng bản sửa lỗi ở trên không hoạt động với họ - nó đã xảy ra với tôi. Một nỗ lực khác để khắc phục sự cố là (cá nhân tôi không xác minh cách giải quyết này):

# setsebool -P use_nfs_home_dirs 1

Một người khác đề cập đến một cái gì đó về GDM, mà tôi không có kiến ​​thức về. Nếu điều đó liên quan đến bạn, tôi khuyên bạn nên đọc bài đăng của anh ấy trong BugZilla và xem nhận xét của anh ấy có ý nghĩa gì với bạn không.


1
Đối với tất cả chiều dài của nó, điều này là không rõ ràng. Vấn đề là gì? Giải pháp / cách giải quyết là gì? Nó làm gì? Khi nào chúng ta nên mong đợi giải pháp số 1 không hoạt động?
Scott

Tôi không hiểu những gì bạn đang hỏi. Câu hỏi đã có một vấn đề khá rõ ràng. Giải pháp 1 đã có một giải pháp khá rõ ràng cho một biến thể của vấn đề đó. Giải pháp 1 có một cách khá rõ ràng để chỉ ra vấn đề cụ thể là gì trong câu trả lời của anh ấy. Vấn đề của tôi rõ ràng khác nhau, như đã chỉ ra ở trên, đó là lý do tại sao giải pháp của tôi để giải quyết vấn đề đó cũng khác biệt rõ ràng. Những gì bạn cần làm rõ về điều đó sẽ làm cho điều này rõ ràng hơn tôi đoán là câu hỏi của tôi cho bạn?
searchengine27

Tôi đã cố gắng thực hiện một số cập nhật cho câu trả lời, nhưng thực lòng tôi không biết làm thế nào để làm cho nó rõ ràng hơn mà không biết điều gì đặc biệt làm phiền bạn về nó.
searchengine27

1
Xác nhận và giải pháp giải quyết vấn đề cho CentOS 6.9
kap

0

Cấu hình SELinux là điều đầu tiên cần kiểm tra, với ...

*/usr/sbin/sestatus*

hoặc là

*/usr/sbin/sestatus -v*

Nếu cấu hình SELinux được đặt thành "Thực thi", nó có thể gây ra sự cố "xauth" .

 /usr/sbin/setenforce 0

Bạn có thể đặt nó tạm thời ở chế độ "cho phép" như sau, (để có thể loại trừ vấn đề này là nguyên nhân gốc rễ của vấn đề) .

Sau đó, làm theo hướng dẫn của Selinux để đặt cấu hình phù hợp hoặc vô hiệu hóa nó nếu bạn thích một phương thức bảo mật khác, (f.ex.by chỉnh sửa tệp cấu hình / etc / selinux / config trong RHEL v.6)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.