Ich habe ein Problem mit der X-Weiterleitung über SSH. Ich kämpfe schon seit Ewigkeiten, aber niemand scheint mir helfen zu können.
Ich gehe jetzt einen anderen Weg. Mich würde interessieren, wie ich die Fehler debuggen kann?
In welchen Protokollen sollte ich nachsehen, welche zusätzlichen Flags sollte ich setzen (-v usw.) und wonach sollte ich suchen?
Weitere Bearbeitung:
Wenn ich mich mit Putty beim Server anmelde und versuche xeyes, erhalte ich Folgendes:
PuTTY X11-Proxy: falsches Autorisierungsprotokoll versuchtFehler: Anzeige kann nicht geöffnet werden: localhost:10.0
Wenn ich xauth generate $DISPLAYbekomme:
PuTTY X11-Proxy: falsches Autorisierungsprotokoll attemptedxauth: (argv):1: Anzeige „localhost:10.0“ kann nicht geöffnet werden.
Antwort1
Meine Lösung Schritt für Schritt:
1) Anmeldung mit der Option -X Remote-Host-Login root
$ ssh -X[email geschützt]
2) Überprüfen Sie, ob eine .Xauthority-Datei vorhanden ist
[root@localhost ~]# ls -al [root@localhost ~]# vim .Xauthority
3) kopiere die .Xauthority Datei in das Verzeichnis des anderen Benutzers
[root@localhost ~]# cp .Xauthority /home/oracle/ cp: „/home/oracle/.Xauthority“ überschreiben? y
4) Berechtigungen für diese Datei festlegen
[root@localhost ~]# chown oracle:oinstall .Xauthority [root@localhost ~]# chmod 0600 .Xauthority
5) Melden Sie sich als Oracle-Benutzer an
[root@localhost ~]# su - Oracle
6) Anzeigeeinstellung in localhost:10.0
[oracle@localhost ~]$ echo $DISPLAY lokaler Host: 10.0 [oracle@localhost ~]$ ls -al
7) listet vorhandene xauth-Cookies auf
[oracle@localhost ~]$ xauth-Liste localhost.localdomain/unix:11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b localhost.localdomain/unix:10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759
8) Hinzufügen
[oracle@localhost ~]$ xauth add localhost.localdomain/unix:10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75
9) Prüfung
[oracle@localhost ~]$ xclock
Hoffe, sie dienen! @wcaraza
Antwort2
Stellen Sie sicher, dass das xauthTool auf dem SSH-Server installiert ist und dass Ihre ~/.XauthorityDatei beschreibbar ist. (Nicht vorhanden ist auch in Ordnung, solange xauthsie erstellt werden kann.)
Überprüfen Sie, ob XAuth-Daten aktualisiert werden:
server$ xauth list
Versuchen Sie, Dummy-XAuth-Daten manuell hinzuzufügen (erneut auf dem SSH-Server) und prüfen Sie, ob xauthProbleme auftreten (z. B. dass die Sperrdatei nicht erstellt oder die XAuthority-Datei selbst nicht geändert werden kann):
server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2
Führen Sie den Vorgang bei Bedarf erneut unter aus strace.
Führen Sie den SSH-Dienst im Debug-Modus aus, indem Sie dies LogLevel DEBUG2in der Serverkonfiguration festlegen ( /etc/ssh/sshd_config), oder indem Sie sshd direkt im Debug-Modus starten:
server$ sshd -rddp 12234
(In diesem Beispiel 12234ist dies der temporäre SSH-Port, mit dem Sie eine Verbindung herstellen müssen. Jeder freie Port ist geeignet.)
Antwort3
Es funktioniert, es funktioniert. haha.
ENDLICH.
Nachdem ich durch das Hinzufügen eines Testbenutzers (mit der X-Weiterleitung funktionierte alles sofort) herausgefunden hatte, dass es nicht am System lag, dachte ich, ich würde anfangen, die .bash*-Startdateien rüberzukopieren, um den „defekten“ Benutzer zu virginisieren.
Keine der Dateien war anders, also habe ich als nächstes das .ssh-Verzeichnis des Benutzers gelöscht. Als ich mich per SSH einloggte, beschwerte es sich über „Der Server hat unseren Schlüssel abgelehnt“, aber ich konnte mich mit einem Passwort anmelden. Nach der Anmeldung konnte ich problemlos x weiterleiten.
Ich werde jetzt versuchen, den Schlüssel erneut einzurichten und sehen, ob ich das auch zum Laufen bekomme. Dann ist alles wieder normal.
Antwort4
rm ~/.Xauth*und dann erneut verbinden.
Das funktioniert bei mir. Für mehrEinzelheiten