2014-09-03 10:44:44 +0000 2014-09-03 10:44:44 +0000
30
30

xauth erstellt keine .Xauthority-Datei

Wenn ich mit ssh in ein kopfloses Linux Mint 17-System scheine, erstellt es kein Update / erstellt keine .Xauthority-Datei.

Wenn ich außerdem xauth ausführe, erhalte ich die Antwort: 

marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>exit
marty@N40L ~ $ xauth
xauth: file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>

Die Datei wird nicht erstellt.

BEARBEITEN:

Wenn ich den Monitor anschließe und mich dann lokal einlogge, wird die Datei erstellt, aber wenn ich versuche, einen Eintrag hinzuzufügen (weil mein SSH es nicht für mich macht): 

marty@N40L ~ $ xauth list
N40L/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep 3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1: unable to open display "localhost:10.0".

Übrigens, wenn ich netstat --listen ausführe, zeigt der Port an, dass er zuhört: 

tcp 0 0 localhost:6010 *:* LISTEN

AGH, mehr Info. Ich habe mich von der X-Sitzung auf dem Server abgemeldet, und jetzt ist die .Xauthority-Datei verschwunden. Es scheint, dass die Datei NUR dann vorhanden ist, wenn sie lokal angemeldet ist. Kann mir jemand sagen, warum, oder wie ich das Problem beheben kann?

NEUE ENTWICKLUNG:

Ich habe auf dem System einen jungfräulichen Benutzer namens “test” angelegt. Dann habe ich mich eingeloggt und ohne irgendeinen anderen Befehl xeyes ausgeführt. Was funktionierte! Es ist also NUR der Benutzer “marty”, der nicht xforward ausführen kann. Wie kopiere ich die Einstellungen von “test” nach “marty”?
Quelle

Antworten (6)

35
35
35
2015-07-16 04:15:44 +0000

Nur um zu berichten, ich hatte ein ähnliches Problem. Aber in meinem Fall befolge ich einfach diese Schritte :

Folgen Sie diesen Schritten, um eine Datei $HOME/.Xauthority zu erstellen.

Melden Sie sich als Benutzer an und bestätigen Sie, dass Sie sich im Home-Verzeichnis des Benutzers befinden. 

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list

Danach gibt es seitdem keine Probleme mehr mit der Datei .Xauthority.

Dank und Anerkennung an srinivasan .
Quelle
4
4
4
2018-02-20 15:30:16 +0000

Nur als Ergänzung zu den ausgezeichneten ton ’s answer .

hatte ich einmal genau das gleiche Problem, weil mein Home-Verzeichnis zu 100% voll geworden war. Beim Anschließen erzeugte ssh eine leere ~/.Xauthority und konnte keinen einzigen Eintrag in dieses Verzeichnis schreiben (so dass xauth list immer eine leere Ausgabe erzeugt hatte).

Ich schlage also vor, man überprüft immer den freien Platz (z. B.: df -h) und verifiziert, dass xauth generate und xauth add tatsächlich irgendeine Wirkung gehabt haben (xauth list).
Quelle
1
1
1
2015-05-20 14:06:07 +0000

Durch das Verschieben des Verzeichnisses .ssh funktionierte die X-Weiterleitung für mich.

Durch einen Eliminationsprozess fand ich eine Datei in ~/.ssh, die “rc” hieß und enthielt: 

echo "Wecome to $(hostname), $(whoami)"

Ich habe diese Datei nie erstellt und habe keine Ahnung, woher sie kam. Durch das Entfernen wurde das Problem behoben, und meine authorized_keys, known_hosts und Schlüsseldateien können alle intakt bleiben.
Quelle
1
1
1
2014-09-04 08:33:25 +0000

Nachdem ich herausgefunden hatte, dass es nicht das System war, indem ich einen Testbenutzer hinzufügte (wobei die x-Weiterleitung “out of the box” funktionierte), dachte ich, ich fange an, die .bash*-Startdateien rüber zu kopieren, um den “kaputten” Benutzer zu jungfräulich zu machen.

Keine der Dateien war anders, also löschte ich als nächstes das .ssh-Verzeichnis des Benutzers. Als ich ssh’d in, stöhnte es über “Server verweigerte unseren Schlüssel”, aber ich konnte mich mit dem Passwort einloggen. Sobald ich eingeloggt war, konnte ich x perfekt weiterleiten.

Ich versuche nun, den Schlüssel erneut einzurichten und zu sehen, ob ich das auch hinbekomme. Dann wird es wieder normal sein.
Quelle
1
1
1
2019-09-17 06:35:46 +0000

Öffnen Sie unter Root-Privilegien /etc/ssh/sshd_config und entkommentieren Sie die folgenden Zeilen, wenn sie kommentiert werden:

X11Forwarding ja

X11DisplayOffset 10

X11UseLocalhost ja

Dann loggen Sie sich aus und wieder mit dem Flag -X in ssh ein. Sie müssen die Umgebungsvariable DISPLAY nicht setzen oder zurücksetzen.
Quelle
0
0
0
2019-01-11 14:16:32 +0000

Ich stieß auf dasselbe Problem auf zwei Servern, die technisch gesehen Schwesterknoten waren. Ich hatte Schmerzen im Hintern, da ich nicht herausfinden konnte, was anders war. Es stellte sich heraus, dass das Verzeichnis /home voll war, so dass die Xauthority-Dateien nicht richtig aufgefüllt werden konnten. Nachdem ich die Datei(en) gefunden hatte, die zu viel Platz beanspruchten, und sie bereinigt hatte, wurden neue .Xauthority-Dateien ordnungsgemäß erstellt.
Quelle