Zunächst einmal, was ich tun möchte:
Ich möchte mich über bei einem Server anmelden ssh. Dann ändere ich den Benutzer über sudo su userund starte eine Anwendung auf meinem Bildschirm.
Einige Kollegen tun dies, indem sie
su user
export DISPLAY=<IP>:0
und es funktioniert.
Ich verbinde mich per mit einem Server ssh -X user@server. Dann starte ich eine X11-Anwendung. Das funktioniert einwandfrei (es gibt allerdings Warnungen).
Warnungen:
libEGL warning: DRI3: failed to query the version
libEGL warning: DRI2: failed to authenticate
qt.qpa.xcb: QXcbConnection: XCB error: 1 (BadRequest), sequence: 414, resource id: 1897, major code: 155 (Unknown), minor code: 1
Wenn ich sudo su(oder sudo su user) ausführe und das Programm starte oder es über ausführe, sudo myprogramtritt ein Fehler auf.
Fehler:
X11 connection rejected because of wrong authentication.
qt.qpa.xcb: could not connect to display localhost:11.0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
Aborted
Ich habe einige Artikel zu diesem Problem gefunden.
Die X11-Weiterleitung schlägt beim Benutzerwechsel fehl
SSH-Verbindung. X11-Verbindung wegen falscher Authentifizierung abgelehnt
Erweitern Sie also die /etc/pam.d/suDatei und die /etc/pam/sudoDatei um
session optional pam_xauth.so
Und später habe ich /etc/ssh/sshd_configFolgendes hinzugefügt:
X11Forwarding yes
und Neustart des sshd durch systemctl restart ssh.service. ssh -Tsagtx11forwarding yes
Aber es änderte sich nichts.
Weiß jemand, was zu tun ist? Es ist wichtig, nach dem Vornehmen von Änderungen einige Änderungen an den Programmkonfigurationen des Benutzers zu überprüfen.
Antwort1
Da viele Leute mit der gleichen Fehlermeldung hierher kommen und nicht erkennen, dass diese nichts mit der Verwendung von zu tun hat su, möchte ich darauf hinweisen, dass ähnliche Symptome jetzt aus einem ganz anderen Grund auftreten:
Alles, was mit Snap installiert wurde, funktioniert nicht. xeyesUnd xclockkönnte also funktionieren, aber eine Neuinstallation von chromium-browseroder firefoxauf Ubuntu funktioniert nicht.
export XAUTHORITY=$HOME/.XauthorityDie Problemumgehung besteht darin, vor dem Ausführen der Remote-X11-Anwendung einfach Folgendes auszuführen :
Antwort2
UnsicherMöglichkeit:
Führen Sie auf dem Host, von dem aus Sie sich anmelden,
xhost +
oder nur ein wenig sicherer
xhost <IP you want to log in to>
Dadurch werden Verbindungen vom Remote-Host ermöglicht.
Warum ist das unsicher? Jedes Programm und jeder Benutzer von diesem Host (oder jedes Programm/jeder Benutzer von jedem Host mit xhost +) kann auf Ihren Bildschirm zugreifen und alle Tastendrücke auf dem Computer lesen, xhostauf dem Sie ausführen.
SichererMöglichkeit:
Fügen Sie dem Remotecomputer den Autorisierungsschlüssel für Ihren X11-Server hinzu:
Listen Sie auf dem lokalen Computer das erforderliche „Magic Cookie“ auf:
# xauth list
hostname/unix:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
Fügen Sie auf dem Remotecomputer das Geheimnis zu Ihrer ~/.XauthorityDatei hinzu. Am einfachsten geht das wieder mit xauth:
# setenv DISPLAY <ORIGIN_IP>:0
# xauth add <ORIGIN_IP>:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
Bitte beachten Sie, dass die X11-Protokolldaten zwischen diesen Maschinen weiterhin unverschlüsselt und daher anfällig für Angriffe sind.
Antwort3
Angenommen, Benutzer1 ist der ursprüngliche Benutzer (dessen Kennwort Sie kennen) und Benutzer2 ist der Zielbenutzer (Kennwort unbekannt), kann ich Folgendes zum Laufen bringen:
% ssh -Y user1@target-box
Password: xxxxxxxxxxxxx
user1@target-box% sudo -u user2 bash
Password: xxxxxxxxxxxxx
user2@target-box% cp ~user1/.Xauthority ~user2
user2@target-box% xterm &
Beachten Sie, dass dies auch die korrekte SSHD-Konfiguration voraussetzt, die Sie in Ihrem Beitrag angegeben haben.