Beim Xforwarding ist kein Benutzerwechsel möglich

8115
Jarvin

Ich bin ssh'd auf einem entfernten Computer und xforwarding funktioniert einwandfrei ... aber sobald ich "sudo su -" oder "sudo su user2" benutze, gibt Xforward nichts mehr aus und gibt mir den Fehler:

X11 connection rejected because of wrong authentication. xterm Xt error: Can't open display: localhost:10.0 

Irgendwelche Ideen?

Vielen Dank

7
Dies ist mehr auf X-Berechtigungen als auf X-Weiterleitung zurückzuführen - der Benutzer, mit dem Sie sich mit SSH angemeldet haben, hat die Berechtigung, eine Verbindung zum X-Display herzustellen, aber wenn Sie Benutzer mit "Sudo" wechseln, hat der Benutzer, zu dem Sie wechseln, keine Berechtigung diese Berechtigungen. quack quixote vor 14 Jahren 1
Es sollte jedoch eine Problemumgehung geben ... Ich habe Root-Zugriff, ich sollte in der Lage sein, eine X11-weitergeleitete App als anderen Benutzer auszuführen. Wie bekomme ich es zur Arbeit? Jarvin vor 14 Jahren 0

5 Antworten auf die Frage

6
Vaibhav Bajpai
  1. Aktivieren Sie die X-11-Weiterleitung in Ihrem Client
  2. Melden Sie sich als normaler Benutzer an
  3. echo $DISPLAY um die zugehörige Anzeige zu erhalten
  4. xauth list, suchen Sie die Displaynummer, die dem entspricht, was Sie in # 3 gefunden haben, und kopieren Sie sie
  5. Sudo zum Wurzeln xauth add <paste in what you copied from #4>
  6. Jetzt können Sie Befehle als root ausführen und die X11 Forwarding-Verbindung sehen
4
tzot

Bevor Sie dies sudotun:

$ xauth extract /tmp/xauthstuff $DISPLAY 

Nachdem Sie dies sudogetan haben:

# xauth merge /tmp/xauthstuff 

Geht das für dich?

PS erinnere dich rm /tmp/xauthstuffdanach

Ich habe diesen Befehl ausprobiert und der Befehl ist fehlgeschlagen: $ xauth extract / tmp / xauthstuff $ DISPLAY Keine Übereinstimmungen gefunden, Berechtigungsdatei "/ tmp / xauthstuff" nicht geschrieben. Ideen? djb vor 13 Jahren 3
Was produziert echo $ DISPLAY? tzot vor 12 Jahren 0
DISPLAY hat den Wert localhost: 10.0 djb vor 10 Jahren 0
3
gannable

Ich habe keinen Zugriff auf das root-Konto, um die oben genannten Aufgaben zu erfüllen. Hier ist eine Umgehung, die ich verwendet habe.

Zuerst ssh zu Ihrem Konto wie üblich und testen, dass alles funktioniert.

ssh -Y <you>@<your_server> 

Normalerweise schalte ich einfach ein XTerm ein, um sicherzustellen, dass ich Konnektivität habe. Wenn alles in Ordnung ist, kopieren Sie die .XAuthority-Datei, die sich im Basisverzeichnis befindet, <you>und legen Sie sie in einem öffentlichen Verzeichnis ab.

cp ~/.Xauthority /tmp/tempXAuth

Stellen Sie sicher, dass Sie chmod 777 für diese Datei im öffentlichen Verzeichnis verwenden, damit das sudo-Konto es später verwenden kann.

chmod 777 /tmp/tempXAuth

Jetzt Sudo für den Benutzer, den Sie als arbeiten müssen

sudo su - <other_user>

wenn Sie sind <other_user>, kopieren Sie sichern die vorhandenen .Xauthority und dann das „gute“ über.

cp ~/.Xauthority ~/.Xauthority.bak cp /tmp/tempXAuth ~/.Xauthority 

Sie sollten in der Lage sein, alle X-Programme auszuführen und sich bei Ihrer aktuellen XServer-Sitzung authentifizieren zu lassen.

2
Tim

Bevor Sie sudo su user2die Berechtigungen für Ihren $ XAUTHORITY prüfen: Wenn Sie nach dem Wechseln des Benutzers immer noch auf denselben $ XAUTHORITY verweisen, jedoch die Berechtigungen für die Datei verloren haben, wird die X11-Weiterleitung abgebrochen. In meinem Fall bestand eine schnelle Lösung darin, die Dateiberechtigungen für die $ XAUTHORITY-Datei anzupassen, bevor der Benutzer gewechselt wurde. Denken Sie daran, dass ein Benutzer, dem Sie nicht vertrauen, auf Ihre $ XAUTHORITY-Datei zugreifen kann, ein Sicherheitsrisiko sein kann.
echo $XAUTHORITY
ls -l $XAUTHORITY





1
user2571962

Als Benutzer, den Sie normalerweise als Typ anmelden:

cd  sudo cp .Xauthority /root/ 

Dann können Sie mit root zu root wechseln.

sudo su