"Su" त्रुटि के साथ "X11 कनेक्शन गलत प्रमाणीकरण के कारण अस्वीकृत"

52

रूट के रूप में, मैं एक कमांड निष्पादित करने के लिए एक दूरस्थ होस्ट से कनेक्ट कर रहा हूं। केवल "मानक" में उचित आईडी-फ़ाइल और सही .ssh / config है, इसलिए मैं पहले उपयोगकर्ता को स्विच कर रहा हूं:

su standarduser -c 'ssh -x remotehost ./remotecommand'

आदेश ठीक काम करता है, लेकिन इस तथ्य के बावजूद कि मैंने "-x" (X11- फ़ॉरवर्डिंग को अक्षम) और X11Forwards को अक्षम करने के बावजूद /etc/ssh/ssh_config, मुझे अभी भी त्रुटि संदेश मिलता है:

X11 connection rejected because of wrong authentication.

जब मैं "मानक" के रूप में लॉग इन करता हूँ तो मुझे त्रुटि संदेश नहीं मिल रहा है।

यह काफी कष्टप्रद है क्योंकि मैं कमांड को क्रोन जॉब फ़ाइल में एकीकृत करना चाहूंगा। मैं समझता हूं कि त्रुटि संदेश रूट की .XAuth फ़ाइल के गलत प्रमाणीकरण को संदर्भित करता है, लेकिन मैं X11 के माध्यम से जुड़ने की कोशिश भी नहीं कर रहा हूं।

"Ssh-x" X11 कनेक्शन को अक्षम करने और त्रुटि संदेश फेंकने में क्यों नहीं है?

अद्यतन : संदेश केवल तभी दिखाता है जब मैं किसी स्क्रीन के भीतर लॉग इन करता हूं, जब स्थानीय मशीन पर ही (स्क्रीन के बिना) ऊपर बताई गई कमांड का उपयोग करते हुए, मुझे कोई त्रुटि संदेश नहीं मिलता है, इसलिए यह क्रोन के साथ ठीक होना चाहिए, भी ।

मैंने भी उसी कमांड के साथ शुरुआत की -vऔर आश्चर्यजनक रूप से त्रुटि संदेश FIRST मिला, SSH से स्थिति की जानकारी से पहले भी:

root@localhost:~# su standarduser -c 'ssh -x remotehost ./remotecommand'
X11 connection rejected because of wrong authentication.
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013

इसने मुझे समस्या के लिए प्रेरित किया, यह वह नहीं है sshजो त्रुटि संदेश फेंक रहा है, यह है su:

root@localhost:~# su standarduser -c 'echo Hi'
X11 connection rejected because of wrong authentication.
Hi

मुझे केवल यह त्रुटि क्यों है screen? मैं इस त्रुटि संदेश को कैसे अक्षम कर सकता हूं?

bash gnu-screen su xauth

— स्टीफन एम
स्रोत

फिर से कमांड चलाएँ और -vssh विकल्पों में जोड़ें , फिर आउटपुट को अपने प्रश्न में पेस्ट करें।

— जेनी डी

79

लगता है जैसे आपकी जड़ में कुछ X11 मैजिक कुकी की कमी है .Xauthority, जो आपके standarduserपास है। इसे ठीक करने का तरीका यहां दिया गया है।

लघु संस्करण ( @bmaupin के लिए धन्यवाद )

standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`

ध्यान दें: backticks की जाँच करें! उन्हें उद्धरण के साथ प्रतिस्थापित नहीं किया जा सकता है! आपको sudoदूसरी कमांड को आगे बढ़ाने के लिए इंस्टॉल करने की आवश्यकता है!

मूल लंबा संस्करण

चीजों को ठीक करने के लिए, पहले पता लगाएं कि कौन सी संख्या संख्या standarduserका उपयोग करती है:

standarduser@localhost:~$ echo $DISPLAY
localhost:21.0

इस मामले में यह है 21.0। दूसरे, standarduserकुकीज़ की सूची प्रदर्शित करें:

standarduser@localhost:~$ xauth list
localhost/unix:1  MIT-MAGIC-COOKIE-1  51a3801fd7776704575752f09015c61d
localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f
localhost/unix:22  MIT-MAGIC-COOKIE-1  22ba6595c270f20f6315c53e27958dfe
localhost/unix:20  MIT-MAGIC-COOKIE-1  267f68b51726a8a381cfc10c91783a13

21.0प्रदर्शन के लिए कुकी सूची में दूसरा है और इसके साथ समाप्त होता है 104f।

आखिरी बात यह है कि इस विशेष कुकी को रूट में जोड़ना है .Xauthority। रूट के रूप में लॉग इन करें और निम्न कार्य करें:

root@localhost:~$ xauth add localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f

X11 connection rejected because of wrong authenticationजब आप suबैश स्क्रिप्ट में एक अलग उपयोगकर्ता के रूप में चलाते हैं तो आप इस त्रुटि को कम कर सकते हैं screen।

प्रेरणा के लिए इस लड़के को धन्यवाद ।

— TranslucentCloud
स्रोत

दिलचस्प। मैंने कोशिश की, लेकिन वह मेरे लिए भी काम नहीं किया। मेरे विशेष मामले में, मैं लगभग कुछ भी (अन्य xterm, वर्चुअलबॉक्स) लॉन्च कर सकता हूं, लेकिन मैं gedit लॉन्च नहीं कर सकता (मुझे वही त्रुटि मिलती है)। हालांकि, अगर मैं रूट में बदल जाता हूं, तो मैं gedit लॉन्च कर सकता हूं। मैंने पत्र के निर्देशों का पालन किया लेकिन कुछ भी नहीं। कुछ और होना चाहिए।

— luis.espinal

@ luis.espinal आशा है कि कोई आपकी विशेष समस्या का समाधान सुझाएगा।

— ट्रांसलूसेंटक्लाउड

1

लंबे संस्करण ने एक आकर्षण की तरह काम किया, लेकिन लघु संस्करण "xauth: (argv): 1: खराब" एड "लाइन"

— सैम

1

लघु संस्करण ने मेरे लिए सेंटोस 7

— tdc

1

Ubuntu पर 18.04.1 लघु संस्करण ठीक काम करता है।

— सिमकिस पनियागोटिस

38

एक आसान समाधान:

1.- ssh user@host

2.- $ sudo su

3.- # xauth merge /home/user/.Xauthority

बस इतना ही

बेशक $DISPLAYचर सेट किया जाना चाहिए।

— जुआन
स्रोत

1

यह आशाजनक लगता है लेकिन थोड़ा अधूरा है। क्या आप $DISPLAYचर सेट करने के बारे में जानकारी जोड़ना चाहेंगे ? मेरा मानना है कि यह छोटा सा जोड़ आपके जवाब के लिए अतिरिक्त आवाज़ें निकाल देगा।

— ट्रांसलूसेंटक्लाउड

यह मेरे लिए काम कर गया, जबकि @ TranslucentCloud का जवाब नहीं था। मुझे मूल रूप से एंड्रॉइड एसडीके प्रबंधक को कमांड लाइन FYI से रूट के रूप में चलाने की कोशिश करते समय समस्या का सामना करना पड़ा।

— स्कूटीसेकस

2

इस के बाद से मेरे लिए बॉक्स से बाहर काम नहीं कियाxauth: file /root/.Xauthority does not exist

— टीडीसी

2

tdc, यह सिर्फ एक चेतावनी है, एक त्रुटि नहीं है, xauth फ़ाइल बनाएगा - यदि आप दूसरी बार कमांड चलाते हैं तो आप इसे नहीं करेंगे।

— व्लादिमीर पेंटेलेव

1

जब आप सिर्फ कॉपी और पेस्ट कर सकते हैं, तो आपको कुछ भी सीखने की जरूरत है! धन्यवाद! रास्ता आसान है।

— सायरन

7

मेरी ज़रूरतें थोड़ी अलग थीं इसलिए मैं थोड़ा अलग समाधान लेकर आया। मुझे एक अन्य उपयोगकर्ता (जो रूट नहीं है) के रूप में एक एक्स 11 ऐप चलाने की क्षमता की आवश्यकता थी। CentOS चल रहा है, इसलिए मेरे पास मीठे गस्कुडो टूल नहीं हैं भाग्यशाली कुत्तों में ubuntu के पास है जो Xauth जादू करता है।

मैं वास्तव में केवल लॉगिन करने, उपयोगकर्ता स्विच करने और ऐप चलाने के लिए कुछ कस्टम स्क्रिप्ट्स को तोड़ना नहीं चाहता था; यह मेरे लिए थोड़ा सतही लगता है।

पहला कदम:

सूडो सत्रों में $ XAUTHORITY को ले जाने की अनुमति दें।

इस पंक्ति को बाकी env_keep कथनों / / / sudoers के अंतर्गत जोड़ें:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

दूसरा चरण:

अपने लक्षित उपयोगकर्ता को आपकी .Xauthority (हाँ मुझे पता है, पढ़ने की क्षमता चिल्लाएँ! आप जो चाहते हैं, उसे पढ़ने की अनुमति दें)। जो लोग केवल कमांड को रूट के रूप में चलाने की क्षमता चाहते हैं, उनके लिए इसे छोड़ दिया जा सकता है।

लक्ष्य उपयोगकर्ता मेरे जैसे ही समूह को साझा करता है इसलिए मैं केवल समूह रीड अनुमतियों को चालू करता हूं:

$ chmod g+r user ~/.Xauthority

तीसरा कदम:

CentOS डिफ़ॉल्ट रूप से $ XAUTHORITY के मूल्य को पॉप्युलेट नहीं करता है। अपने प्रोफ़ाइल में एक पंक्ति जोड़ें (मेरा है ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

बस। और कोई ट्विकिंग नहीं। कोई लेखन नहीं। प्रत्येक लॉगिन के लिए कोई रनिंग स्क्रिप्ट नहीं। कोई दो बार sudo करने के लिए xauth की प्रतिलिपि बनाएँ। यहाँ से बाहर, आप बस कर सकते हैं:

$ sudo -u user xcalc

MobaXTerm के साथ बढ़िया काम करता है।

— डब्ल्यू स्मिथ
स्रोत

यह सिर्फ वही था जो मुझे उस समस्या को हल करने के लिए था जो मुझे CentOS 7 पर वीएम कंसोल प्राप्त करने के साथ हो रही थी। मुझे वास्तव में केवल अपने उद्देश्य के लिए चरण तीन करने की आवश्यकता थी (और, निश्चित रूप से, सुनिश्चित करें कि X11Forwarding हाँ / etc / में सेट करने के लिए सेट किया गया था) ssh / sshd_config)। धन्यवाद।

— अन्धकार

बहुत बढ़िया! यह जवाब है! धन्यवाद @ स्मिथ

— tmow

1

आपको लक्ष्य उपयोगकर्ता पर पूरी तरह से स्विच करना चाहिए, अर्थात " -" के साथ su( su - standarduser ...) का उपयोग करें । यदि नहीं, तो रूट का X सामान पर्यावरण में चारों ओर खींच लिया जाएगा।

— जेरी एपस
स्रोत

0

क्योंकि मैं अक्सर रूट-स्क्वैश नेटवर्क फ़ाइल शेयर पर रूट करता हूं, उपरोक्त समाधानों में से कोई भी मेरे लिए काम नहीं करता है। (xubuntu 14.04)। मैंने निम्नलिखित स्क्रिप्ट को एक साथ रखा, जो मेरे सिस्टम पर काम करता है। यह आपके काम आ सकता है। तो फिर, यह नहीं हो सकता है, लेकिन यह कोशिश करने के लिए स्वतंत्र है ...

मान लें कि मैंने s -'d विकल्प का उपयोग किया है।

#!/bin/bash  
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
    port=${BASH_REMATCH[1]}
else
    echo "Unexpected DISPLAY $DISPLAY"
    exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
sudo -i xauth -i add $cookie
sudo -i $*

— जेरार्ड
स्रोत

cookie=$(xauth list|grep $h.*$port)अगर पोर्ट $ कुकी मूल्य का हिस्सा होता है तो लाइन का उद्देश्य से अधिक मिलान हो सकता है। सुरक्षित है: cookie=$(xauth list) cookie=${c%% *}या cookie=$(xauth list |grep $h[^ ]*$port)।

— पेपा

0

मेरे मामले में, जब मुझे उस त्रुटि का सामना करना पड़ा, तो मेरे पास एक एन्क्रिप्टेड उपयोगकर्ता निर्देशिका थी। कॉल करने के बाद ecrypt-mount-private, यह त्रुटि से मुक्त हो गया और मुझे X11 अग्रेषण जारी रखने की अनुमति दी।

यह निर्धारित करने के लिए कि क्या आपके होम फ़ोल्डर को एन्क्रिप्ट किया गया है, आप इसे ( इस उत्तर के अनुसार ) आज़मा सकते हैं ls -A /home:। यदि आप एक .ecryptfsफ़ोल्डर देखते हैं , तो आपके होम डायरेक्टरी को शायद एन्क्रिप्ट किया गया है, जिस स्थिति में आप उत्तर के प्रारंभ में मेरे द्वारा लगाई गई कमांड को करने का प्रयास कर सकते हैं।

— हेनरी
स्रोत