Wie debugge ich "X11-Verbindung wegen falscher Authentifizierung abgelehnt"

10

Ich habe ein Problem mit der X-Weiterleitung über SSH. Ich habe ewig gekämpft, aber niemand kann helfen.

Ich gehe jetzt einen anderen Takt ein. Ich möchte wissen, wie ich die Fehler debuggen würde.

In welchen Protokollen sollte ich suchen, welche zusätzlichen Flags sollte ich setzen (-v usw.) und wonach sollte ich suchen?

Weitere Bearbeitung:

Wenn ich mich bei Putty auf dem Server anmelde und es versuche xeyes, erhalte ich:

PuTTY X11-Proxy: Falsches Autorisierungsprotokoll versucht. Fehler: Anzeige kann nicht geöffnet werden: localhost: 10.0

Wenn xauth generate $DISPLAYich bekomme:

PuTTY X11-Proxy: Falsches Autorisierungsprotokoll versuchtxauth: (argv): 1: Anzeige "localhost: 10.0" kann nicht geöffnet werden.

— wkdmarty
quelle

In Ihrer Frage vom anderen Tag beschreiben Sie verschiedene Symptome. Leiden Sie immer noch unter "Anzeige kann nicht geöffnet werden" oder haben Sie das gelöst? Wenn Sie das gelöst haben und eine der Antworten auf diese Frage hilfreich war, sollten Sie sie als Antwort auswählen, um die Person zu belohnen, die Ihnen geholfen hat.

— Kenster

Einverstanden, es ist jetzt ein anderer Fehler, ich habe diese Frage geschlossen.

— wkdmarty

Überprüfen Sie, ob diese Antwort für Ihren Server gilt.

— Kenster

Kenster, ich hatte keine RC-Datei auf dem Server, also habe ich eine erstellt und den Code eingefügt. Kein Unterschied.

— wkdmarty

In den PuTTY-Protokollen wird dies angezeigt, nachdem ich versucht habe, ein x-Programm auszuführen (nach der SSH-Anmeldung). 2014-09-01 15:16:38 X11-Verbindungsanforderung von 127.0.0.1:59566 empfangen 2014-09-01 15:16:38 Öffnen der X11-Vorwärtsverbindung erfolgreich 2014-09-01 15:16:38 Es ist nichts mehr zu senden, Kanal schließen 2014-09-01 15:16:38 Weitergeleitete X11-Verbindung beendet

— wkdmarty

13

Meine Lösung Schritt für Schritt:

1) Melden Sie sich mit der Option -X Remote Host Login Root an

$ ssh -X root@192.168.1.39

2) Überprüfen Sie, ob eine .Xauthority-Datei vorhanden ist

[root @ localhost ~] # ls -al
[root @ localhost ~] # vim .Xauthority

3) Kopieren Sie die .Xauthority-Datei in das Verzeichnis des anderen Benutzers

[root @ localhost ~] # cp .Xauthority / home / oracle /
cp: `/home/oracle/.Xauthority 'überschreiben? y

4) Legen Sie die Berechtigungen für diese Datei fest

[root @ localhost ~] # chown oracle: ostall .Xauthority
[root @ localhost ~] # chmod 0600 .Xauthority

5) Orakelbenutzer anmelden

[root @ localhost ~] # su - oracle

6) Anzeigeeinstellung in localhost: 10.0

[oracle @ localhost ~] $ echo $ DISPLAY
localhost: 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) testen

[oracle @ localhost ~] $ xclock

Hoffe sie dienen! @wcaraza

— Walter Caraza
quelle

2

Der Teil xauth hinzufügen .... ist der Trick

— Wei

Schritte 3. und 4. haben den Trick für mich gemacht

— Kiltek

6

Stellen Sie sicher, dass auf dem SSH-Server das xauthTool installiert ist und Ihre ~/.XauthorityDatei beschreibbar ist. (Nicht vorhanden ist auch in Ordnung, solange es erstellt werden xauthkann.)

Überprüfen Sie, ob die 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 vorliegen (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

Falls erforderlich, führen Sie unter erneut aus strace.

Führen Sie den SSH-Dienst im Debug-Modus aus, indem Sie LogLevel DEBUG2die Serverkonfiguration ( /etc/ssh/sshd_config) festlegen oder sshd direkt im Debug-Modus starten:

server$ sshd -rddp 12234

(In diesem Beispiel 12234ist dies der temporäre SSH-Port, zu dem Sie eine Verbindung herstellen müssen. Jeder freie Port reicht aus.)

— user1686
quelle

Vielen Dank. Xauth auf dem Server kann in die .Xauthority-Datei schreiben. Aber was soll es einstellen? Server = N40L, Client = Lin001. Sollte die xauth-Liste auf N40L einen Eintrag für localhost enthalten: 10 MIT-MAGIC-COOKIE-1 {Lin001'sHexKey}?

— wkdmarty

@wkdmarty: Ja, Ihr sshd überwacht einen TCP-Port, der Anzeige: 10 (oder: 11 ,: 12 ...) entspricht, und dies wird als "localhost: 10" angezeigt. Was den Hex-Schlüssel betrifft, weiß ich nicht wirklich, ob er denselben Schlüssel verwenden soll - ich denke, ssh generiert tatsächlich einen neuen und fungiert als Proxy ...

— user1686

ok perfekt, ich kann sehen, dass 0.0.0.0:6011 zuhört. Meine DISPLAY-Variable gibt N40L: 11.0 an, was ich für falsch halte. Deshalb werde ich das in DISPLAY = localhost: 10.0 ändern. Nein, immer noch fehlerhaft. Ich habe bei der SSH-Verbindung diese Zeile bemerkt: debug2: x11_get_proto / usr / bin / xauth Liste: 0.0 2> / dev / null Wo immer ich die SSH-Verbindungsprotokollierung gesehen habe, ist diese Zeile anders ... zeigt eine Schlüsselgenerierung, niemals : 0,0.

— wkdmarty

@wkdmarty: Normalerweise sollte sshd $ DISPLAY auf den richtigen Wert setzen ... und Port 6011 entspricht sowieso Anzeige 11, nicht 10.

— user1686

1

"Meine DISPLAY-Variable gibt N40L: 11.0 an ... also werde ich das ändern". Um stumpf zu sein, lassen Sie DISPLAY in Ruhe. Wenn ssh die X11-Weiterleitung einrichtet, wird DISPLAY auf einen Wert gesetzt, der funktioniert. Das Überschreiben des von ssh festgelegten Werts erschwert lediglich die Fehlerbehebung.

— Kenster

3

Es funktioniert, es funktioniert. Haha.

SCHLIESSLICH.

Nachdem ich herausgefunden hatte, dass es nicht das System war, dachte ich durch Hinzufügen eines Testbenutzers (dessen x-Weiterleitung "out the box" funktionierte), ich würde anfangen, die .bash * -Startdateien zu kopieren, um den "kaputten" Benutzer zu jungfräulich zu machen.

Keine der Dateien war anders, also habe ich als nächstes das .ssh-Verzeichnis des Benutzers gelöscht. Als ich mich einschrieb, stöhnte es über "Server hat unseren Schlüssel abgelehnt", aber ich konnte mich mit einem Passwort anmelden. Einmal eingeloggt, konnte ich x perfekt weiterleiten.

Ich werde jetzt versuchen, den Schlüssel erneut einzurichten und zu sehen, ob ich das auch zum Laufen bringen kann. Dann wird es wieder normal.

— wkdmarty
quelle

Das hat auch bei mir funktioniert. Ich habe alle anderen Methoden ausprobiert, aber anscheinend lag das Problem in den Schlüsseln.

— Hilfs

1

Eine weitere Ursache für dieses Problem ist das Vorhandensein einer ~/.ssh/rcDatei auf dem Server - dem Computer, mit dem Sie eine Verbindung herstellen. Löschen Sie es (oder benennen Sie es um), um das Problem zu lösen.

— Ken Jackson
quelle

1

Per man sshd, sshd läuft ~/.ssh/rcanstelle von xauth@PimpJuiceIT.

— Ken Jackson

Vielen Dank! Weitere Informationen finden Sie unter: docstore.mik.ua/orelly/networking_2ndEd/ssh/… . Es sollte möglich sein, die entsprechenden Befehle zum Starten von xauth in der rc-Datei hinzuzufügen, aber ich habe sie nicht gefunden.

— Matt B.

0

rm ~/.Xauth* und dann wieder verbinden.

Das funktioniert bei mir. Für weitere Details

— zzz92
quelle