मुझे यह संदेश xauth से क्यों मिल रहा है: "लॉकिंग अथॉरिटी फ़ाइल /home/<user>/.Xauthority में टाइमआउट"?

Question

एक मेजबान में 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

मेरे द्वारा इस समस्या का समाधान कैसे किया जा सकता है?

Comments

मुझे यह पृष्ठ मददगार लगा, क्योंकि मेरा मुद्दा सेलिनक्स को लागू करने वाले मोड में होने के कारण था, जो फ़ाइल को पहली बार में बनाए जाने से रोक रहा था: twiki.cern.ch/twiki/bin/view/CLIC/LCDTbbleSolution

— Gav Reichel

Answer 1

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

जीयूआई

$ 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 "लॉकिंग अथॉरिटी फ़ाइल में त्रुटि" त्रुटियों से निपटना

Comments

क्या आप जानते हैं कि उन लॉक फाइलों के पीछे क्या कारण था?

— गिल्स एसओ- बुराई को रोकना '

@ गिल्स - नहीं, मेरा भी यही विचार था। मैंने उन्हें डिलीट कर दिया और फिर सोचा, मुझे इसका उपयोग करने को नियंत्रित करने की कोशिश करनी चाहिए lsof। मैंने उन्हें पहले देखा था लेकिन याद नहीं कर पा रहा हूँ। मुझे लगा कि आप और मैंने एक बिंदु पर उनसे पहले चर्चा की लेकिन साइट पर उनका कोई उल्लेख नहीं मिला।

— स्लम

प्राधिकरण फ़ाइलों को हटाने से पहले आपको SELinux मुद्दों को ठीक करने की आवश्यकता हो सकती है। देखें froebe.net/blog/2015/01/20/…

— MrMas

मेरे मामले में फ़ाइल और निर्देशिका में गलत स्वामी था (उपयोगकर्ता के होम निर्देशिका को किसी अन्य कंप्यूटर पर कॉपी करने के बाद)।

— केन शार्प

मेरे मामले में / home / उपयोगकर्ता फ़ोल्डर की अनुमति root:rootइसके बजाय थी user:user। द्वारा तय किया गया chown user:user /home/user।

— १and

Answer 2

समस्या की जड़ यह हो सकती है कि आपके पास $ HOME निर्देशिका में कोई लिखित अनुमति न हो।

इसलिए मुझे यह संदेश मिला:

/ usr / bin / xauth: लॉकिंग अथॉरिटी फ़ाइल में टाइमआउट /home/fooftp/.Xautroity

यहां मैंने अनुमति की जांच की है:

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

Answer 3

मेरे पास इस सवाल का एक और जवाब है कि इससे पहले कि मैं इस मुद्दे का पता लगाऊं। यह मुद्दा फेडोरा ओएस में एक बग है और यह डेरिवेटिव है, जैसा कि मैंने बाद में पता लगाया। यदि समस्या स्वीकार किए गए उत्तर द्वारा इंगित नहीं की गई है, और / या आप फेडोरा, रेडहैट, कोरोरा, आदि पर नहीं हैं, तो यह आपकी मदद नहीं करेगा।

समस्या

जैसा कि यूजर स्लम ने कहा, स्ट्रींग चलाने से आपको समस्या का संकेत मिलेगा, लेकिन इस विशेष बग के मामले में, आउटपुट बहुत अलग है:

$ 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 रिटर्न कोड था, जिसका अर्थ है फ़ाइल मौजूद है। तो, EACCES रिटर्न कोड के लिए, स्पष्ट रूप से आपके द्वारा जांची जाने वाली पहली चीज़ है: क्या मेरे घर की अनुमतियां स्थापित की गई हैं, इसलिए मैं अपने होम निर्देशिका में लिखने में सक्षम हूं? आपको यह सत्यापित करना चाहिए कि आपके पास पहले अपने स्वयं के उपयोगकर्ता के लिए अपने होम डायरेक्टरी पर लिखने का झंडा है। यदि आप करते हैं, तो आप नीचे वर्णित बग का शिकार हो सकते हैं।

बग

एक युगल Google खोजों के माध्यम से मैं आखिरकार एक समान समस्या वाले किसी व्यक्ति को ढूंढने में सक्षम था, और इसने मुझे फेडोरा बग की रिपोर्ट के लिए प्रेरित किया। आप में से जो इसके बारे में पढ़ना चाहते हैं, उनके लिए: https://bugzilla.redhat.com/show_bug.cgi?id=777992

वर्कअराउंड

समस्या का समाधान:

#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 में वापस आते हैं, तो यह इस बिंदु पर ठीक होना चाहिए और आपको अपने एक्स-सत्र को फिर से सफलतापूर्वक स्थानांतरित करने में सक्षम होना चाहिए।

---

EDIT (और अन्य वैकल्पिक समाधान):

बस जितना संभव हो उतना पूरा होने के लिए, अन्य उपयोगकर्ताओं ने बग रिपोर्ट में बताया कि ऊपर का फिक्स उनके लिए काम नहीं करता था - यह मेरे लिए काम करने के लिए हुआ। समस्या के आसपास काम करने का एक और प्रयास था (मैंने व्यक्तिगत रूप से इस वर्कअराउंड को सत्यापित नहीं किया है):

# setsebool -P use_nfs_home_dirs 1

एक अन्य व्यक्ति GDM के बारे में कुछ उल्लेख करता है, जिसके बारे में मुझे शून्य ज्ञान है। अगर वह आपसे संबंधित है, तो मैं बुग्जिला में उसकी पोस्ट को पढ़ने और यह देखने की सलाह देता हूं कि क्या उसकी टिप्पणी का आपके लिए कोई मतलब है।

Comments

इसकी सभी लंबाई के लिए, यह अस्पष्ट है। समस्या क्या है? समाधान / समाधान क्या है? यह क्या करता है? जब हमें समाधान # 1 काम नहीं करने की उम्मीद करनी चाहिए?

— स्कॉट

मुझे समझ नहीं आ रहा है कि आप क्या पूछ रहे हैं। सवाल एक बहुत स्पष्ट समस्या थी। समाधान 1 में उस समस्या की भिन्नता के लिए एक बहुत स्पष्ट समाधान था। समाधान 1 में यह इंगित करने का एक बहुत स्पष्ट तरीका था कि विशेष रूप से उसके जवाब में क्या समस्या थी। मेरी समस्या स्पष्ट रूप से अलग थी, जैसा कि ऊपर बताया गया है, यही वजह है कि उस समस्या को हल करने का मेरा समाधान भी स्पष्ट रूप से अलग था। इस पर आपको स्पष्टीकरण की क्या आवश्यकता है, इससे मुझे और स्पष्ट होगा कि मेरा अनुमान आपसे प्रश्न है?

— searchengine27

मैंने उत्तर के लिए कुछ अपडेट करने की कोशिश की, लेकिन मैं ईमानदारी से नहीं जानता कि इसे कैसे और अधिक स्पष्ट किया जाए, बिना यह जाने कि इसके बारे में विशेष रूप से आपको क्या परेशानी है।

— searchengine27

पुष्टि की और वर्कअराउंड CentOS 6.9

— kap

Answer 4

SELinux कॉन्फिगरेशन सबसे पहली चीज़ है, जिसकी जाँच ...

*/usr/sbin/sestatus*

या

*/usr/sbin/sestatus -v*

यदि SELinux कॉन्फ़िगरेशन "Enforcing" पर सेट है, तो यह "xauth" समस्या पैदा कर सकता है।

 /usr/sbin/setenforce 0

आप इसे अनंतिम रूप से "अनुमति" मोड में निम्नानुसार सेट कर सकते हैं, (समस्या के मूल कारण के रूप में इस मुद्दे को बाहर करने में सक्षम होने के लिए) ।

फिर एक उचित कॉन्फ़िगरेशन रखने के लिए एक SELinux ट्यूटोरियल का अनुसरण करें, या यदि आप किसी अन्य सुरक्षा विधि, (f.ex.by / the / etc / selinux / config कॉन्फ़िगरेशन फ़ाइल RHEL v.6 में संपादित करना चाहते हैं) को अक्षम करें।